Pelt8 · Diseñar más allá del producto

Pelt8 era una startup suiza de reporting ESG. Mi relación con el proyecto comenzó en 2021, cuando su fundador, Julian Osborne, me contactó para transformar una visión inicial en un prototipo que pudiera enseñar y validar con posibles usuarios.

Julian había sido mi Product Owner en HedgePilot durante mi etapa en LPA. Ya conocía mi trabajo y recurrió a mí cuando necesitó una diseñadora que pudiera ayudarle a estructurar el producto desde sus primeras hipótesis.

Después de aquella colaboración inicial, Julian continuó desarrollando y validando Pelt8. Yo apoyé ocasionalmente el proyecto hasta incorporarme plenamente en 2023 como Lead Designer y única diseñadora del equipo. Para entonces, Pelt8 era una aplicación en React utilizada por clientes reales y mi responsabilidad había cambiado: debía aportar coherencia al producto, establecer una base común para Design y Development y mantener la calidad de la marca en todos sus puntos de contacto.

Responsabilidad: Product UX/UI · Design System · marca · web · email · comunicación · no-code y automatización.

Una invitación basada en confianza previa

A comienzos de 2021, Julian estaba trabajando solo en una idea llamada Pelt8. Después de nuestra primera conversación me compartió un pitch preliminar, un documento conceptual sobre la organización que quería construir y un mapa de páginas y funcionalidades en Figma.

El objetivo inmediato era crear un prototipo que pudiera enseñar a posibles usuarios para obtener feedback. También necesitaba una primera página de acceso al producto. Si las señales eran positivas, la intención era avanzar hacia una versión funcional y utilizar el interés de posibles clientes para buscar financiación.

El material explicaba la ambición de Pelt8, pero todavía no existía una experiencia de producto capaz de mostrar cómo funcionaría.

Comprender el dominio antes de diseñar la interfaz

Yo no conocía el mundo ESG. Antes de dibujar pantallas necesitaba entender qué problema quería resolver Pelt8, cómo funcionaba el proceso completo y qué información requerían las personas implicadas.

La primera propuesta se centraba en ayudar a organizaciones de private capital markets a identificar los KPIs y estándares relevantes, solicitar información a distintas organizaciones, monitorizar el progreso y crear reportes para inversores y otros stakeholders.

Además, el producto debía atender dos perspectivas conectadas pero diferentes:

• la organización que definía indicadores, solicitaba información y consolidaba los resultados;
• la entidad que recibía la solicitud y aportaba los datos.

Investigué el dominio, revisé referencias y productos comparables y utilicé low-fi para hacer visibles las relaciones que todavía no estaban resueltas. El propósito de esa fase no era dominar toda la regulación ESG, sino adquirir la comprensión necesaria para formular mejores preguntas y convertir la lógica del negocio en una experiencia coherente.

Del mapa de funcionalidades a un recorrido de producto

El Figma inicial de Julian organizaba páginas y funcionalidades mediante MoSCoW: must have, enabling functions, could have y wishlist. Era una base útil para priorizar, pero no explicaba cómo se conectaban las acciones, qué decisiones debía tomar cada usuario ni cómo se completaba un proceso de principio a fin.

Empecé construyendo maps, user journeys y flows. Un recorrido general conectaba el acceso, los perfiles de organización, las fuentes de terceros, Indicators, Measures, Metrics y Reports. Otro profundizaba en la creación de una Metric: su periodicidad, responsable, pertenencia a un reporte, datos de origen, operadores y fórmula.

A partir de esos recorridos conceptualicé pantallas low-fi. Los wireframes no eran una versión visualmente incompleta del producto final; eran una herramienta para convertir preguntas abstractas en decisiones observables. Julian podía seguir la lógica, detectar vacíos y discutir cómo debería comportarse el producto antes de invertir en su construcción.

De prototipar una posibilidad a trabajar dentro de un SaaS en producción

Cuando me incorporé plenamente en 2023, Pelt8 ya no era un conjunto de hipótesis. Era una aplicación construida en React, con clientes y un equipo de Development que llevaba tiempo resolviendo las necesidades del negocio.

Ese crecimiento también había dejado inconsistencias visuales, patrones que se comportaban de manera diferente y decisiones de experiencia tomadas sin una función de diseño dedicada. Mi primera responsabilidad fue auditar el producto para reconocer problemas recurrentes y separar tres niveles de trabajo:

1. correcciones que podían mejorar la experiencia de inmediato;
2. problemas estructurales que requerían patrones compartidos;
3. oportunidades que debían formar parte de una evolución futura.

La auditoría no pretendía producir una lista aislada de errores. Me permitió construir una visión del producto, comprender las decisiones que ya existían y establecer prioridades junto con Product y Engineering.

Diseñar dentro del ritmo del equipo

Trabajábamos por sprints. Colaboraba con el Product Owner y el Product Manager para comprender necesidades, definir funcionalidades, discutir mejoras y acordar el alcance. Diseñaba nuevas pantallas y revisaba experiencias existentes, pero mi responsabilidad no terminaba al entregar un archivo de Figma.

Durante la implementación permanecía disponible para resolver dudas, revisar alternativas y hacer QA. El flujo real era continuo:

Necesidad → definición con Product → exploración → diseño → conversación técnica → trade-off → implementación → QA → documentación

Mis conocimientos de frontend me ayudaban a comprender qué cambios podían incorporarse con menor esfuerzo y cuáles tenían implicaciones mayores. Esto facilitaba conversar con Development desde las restricciones reales y proteger los elementos esenciales de la experiencia sin plantear soluciones desconectadas de la capacidad del equipo.

Una función de diseño transversal

Mi rol formal incluía supervisar el diseño desde la concepción hasta la entrega, asegurar la facilidad de uso de la aplicación, mantener la consistencia de marca, contribuir a métodos de research, liderar la experiencia de la web y crear materiales de marketing.

En la práctica, esto significaba conectar producto, desarrollo, comunicación y operaciones. No se trataba de ocupar distintos roles de manera indiscriminada, sino de reconocer dónde una decisión de diseño podía reducir fricción, crear coherencia o ayudar al equipo a avanzar.

Metrics: un problema técnico que también necesitaba dirección de diseño

Pelt8 debía representar relaciones entre Measures, Metrics, Frameworks y Reports. Una Measure era un dato utilizado por el sistema; una Metric podía combinar distintas Measures mediante una fórmula. La complejidad formaba parte del dominio y de la flexibilidad que necesitaban los usuarios, por lo que no podía eliminarse sin más.

Antes de mi incorporación, el equipo de Development había resuelto la creación de fórmulas mediante una implementación basada en nodos desplegables. Fue una respuesta pragmática para dar salida con rapidez a un problema técnico complejo cuando todavía no existía una dirección de diseño dedicada.

La solución hacía posible construir las fórmulas, pero presentaba dificultades de uso. Costaba distinguir la jerarquía, comprender qué elementos pertenecían a cada nivel, seguir las dependencias y leer con claridad el resultado que se estaba construyendo.

El reto no era cuestionar la decisión anterior, sino comprender por qué se había tomado y diseñar una evolución compatible con la realidad del producto.

Diseñar una transición, no únicamente un resultado ideal

Engineering tenía una carga de trabajo elevada y reemplazar por completo la implementación no era viable de inmediato. Por eso organicé la propuesta en tres niveles:

1. Quick wins. Ajustes de menor implementación para mejorar el espaciado, la pertenencia, la jerarquía y las pistas visuales.
2. Mejoras estructurales. Cambios en la organización de los elementos para hacer más legibles las relaciones y dependencias.
3. Target vision. Una dirección futura de interacción que mostraba cómo podría evolucionar el sistema con mayor disponibilidad técnica.

Este enfoque convertía el diseño en una conversación sobre coste, impacto y secuencia. En lugar de presentar una solución de todo o nada, permitía mejorar la experiencia desde el corto plazo mientras manteníamos una visión compartida para el futuro.

No bastaba con diseñar una solución ideal. También era necesario diseñar un camino viable para llegar hasta ella.

Metrics resume una parte importante de mi trabajo en Pelt8: aprender un concepto especializado, distinguir la complejidad necesaria de la fricción evitable y traducir una visión de UX en etapas que el equipo pudiera implementar.

De corregir pantallas a identificar patrones

Pelt8 no tenía un Design System estructurado cuando me incorporé. A medida que auditaba y rediseñaba el producto aparecía el mismo patrón: muchas inconsistencias no podían resolverse pantalla por pantalla porque procedían de la ausencia de foundations, componentes y criterios compartidos.

Empecé construyendo las bases que necesitábamos para los problemas inmediatos. El sistema evolucionó con el producto:

Sin sistema → foundations propias → mayor alineación con Material → UI kit adaptado → componentes adicionales → documentación

La alineación con Material no consistió en adoptar una librería sin criterio. Nos proporcionaba una base reconocible y sostenible, mientras que el UI kit adaptado permitía conservar las necesidades y el lenguaje visual de Pelt8.

El objetivo no era alcanzar una madurez teórica ni crear una biblioteca enorme. Era construir el nivel de consistencia que una startup pequeña pudiera mantener y utilizar en su trabajo diario.

Documentar para reducir dependencia

El sistema no vivía únicamente en Figma. Empecé a documentar en Notion:

• componentes y patrones;
• principios de diseño;
• criterios para decisiones recurrentes;
• pautas de handoff;
• buenas prácticas para la implementación.

La documentación era parte de la solución. Permitía que Development consultara decisiones existentes, resolviera más situaciones con autonomía y redujera preguntas repetitivas. También evitaba que el conocimiento permaneciera únicamente en conversaciones o dependiera de mi disponibilidad.

Una integración más madura entre diseño y código, mediante herramientas como Storybook, formaba parte de la visión futura. Sin embargo, el tiempo y las prioridades del producto no permitían construir y mantener esa infraestructura.

Figma acompañado de documentación en Notion fue el primer paso viable: no eliminaba toda la distancia entre diseño y código, pero creaba un lenguaje común y una referencia que el equipo sí podía mantener.

Diseñar también la colaboración

El Design System no funcionaba de manera aislada. Revisaba implementaciones, respondía dudas durante los sprints y ajustaba las propuestas cuando surgían restricciones. Cada problema resuelto podía convertirse en un patrón; cada patrón documentado evitaba comenzar desde cero la siguiente vez.

Una iniciativa de negocio sin capacidad de Development

En una colaboración vinculada al sector bancario, Pelt8 necesitaba lanzar una experiencia adicional en un plazo limitado. El equipo de Development estaba concentrado en el producto principal y no podía abrir otro proyecto.

Esperar habría bloqueado la iniciativa. Construir una aplicación a medida habría consumido una capacidad que no existía. Antes de elegir una herramienta, investigué distintas alternativas no-code y valoré qué combinación podía ofrecer:

• lógica condicional;
• rapidez de construcción;
• integración con los procesos existentes;
• comunicaciones automatizadas;
• una operación asumible para el equipo.

Tally y Make ofrecían la combinación más viable para responder al alcance y al tiempo disponible. La decisión no partió de querer utilizar esas herramientas, sino de evaluar qué medio permitía resolver mejor el problema bajo las restricciones reales.

Construir el recorrido completo

En Tally diseñé la experiencia basada en preguntas y ramificaciones. Las respuestas conducían a resultados u ofertas diferentes. Después utilicé Make para conectar el recorrido con las acciones posteriores:

• generar comunicaciones según el resultado;
• enviar emails automáticamente;
• trasladar acciones de seguimiento al sistema de tareas;
• permitir que el equipo operara la iniciativa sin depender de una nueva aplicación.

La solución no intentaba reemplazar el producto principal ni convertirse en una plataforma paralela. Era una respuesta proporcionada: suficientemente sólida para cumplir el objetivo sin consumir el roadmap de Engineering.

Este trabajo demuestra que resolver no siempre significa diseñar una pantalla para que otra persona la construya. También puede significar investigar opciones, seleccionar la arquitectura más viable y llevar la experiencia hasta un estado operativo.

Una identidad coherente en todos los puntos de contacto

Como única diseñadora, también era responsable de cómo Pelt8 aparecía fuera del SaaS. Realicé un restyling de la identidad y trabajé para trasladar el nuevo lenguaje visual a la web, las redes sociales, las presentaciones, los pitch decks, los materiales para clientes y fundraising, las piezas impresas y los eventos.

La web existente estaba alojada en WordPress. Propuse reconstruirla en Framer porque ofrecía mayor control sobre el diseño, más autonomía para mantener el contenido y una continuidad más directa entre Figma y la implementación. Esto permitía iterar con mayor rapidez, mejorar la experiencia y reducir la dependencia técnica para ajustes cotidianos.

Mejorar las comunicaciones desde la herramienta existente

Brevo ya era la plataforma definida por la empresa para sus comunicaciones. Mi trabajo fue entrar en ese sistema y mejorar la experiencia desde dentro.

Diseñé templates y assets, organicé la lógica de distintos mensajes y trabajé tanto en emails transaccionales enviados por la aplicación como en comunicaciones destinadas a informar a los clientes sobre nuevas releases. Para adaptar las plantillas a las necesidades visuales y funcionales de Pelt8, también trabajé directamente con HTML y CSS dentro de Brevo.

Así, la comunicación posterior a una acción o a una actualización del producto mantenía continuidad con la interfaz y con la identidad de Pelt8. El diseño no terminaba en la pantalla principal: incluía los mensajes que acompañaban al usuario antes y después de utilizarla.

Diseñar también los momentos públicos de la empresa

Creé materiales para redes sociales, ventas, clientes y fundraising. También desarrollé la gráfica del Swiss Climate Reporting Forum y apoyé visualmente sus dos ediciones.

Además de producir piezas concretas, diseñé templates reutilizables para presentaciones y documentos, disponibles tanto en Canva como en Figma. Preparé alternativas en ambas herramientas porque algunos miembros del equipo se sentían más cómodos trabajando en Canva y otros en Figma. Así, los founders contaban con lineamientos visuales claros y podían crear contenido con rapidez sin perder la consistencia de la marca ni detener necesidades urgentes de la startup a la espera de apoyo de diseño.

La diversidad de formatos podía parecer una suma de tareas distintas, pero respondía al mismo objetivo: mantener una experiencia reconocible y profesional, mientras el equipo ganaba autonomía para moverse con velocidad.

Mi trabajo en Pelt8 evolucionó junto con la empresa. Comenzó dando estructura visual y lógica a una idea que todavía necesitaba validarse. Continuó dentro de un producto real, donde diseñar significaba comprender restricciones, negociar prioridades y acompañar la implementación. Finalmente, se convirtió en una función transversal capaz de conectar producto, sistemas, marca y operaciones.

El impacto no estuvo únicamente en las pantallas producidas:

• En el producto, convertí complejidad en recorridos y estrategias de mejora que Development pudiera implementar.
• En el equipo, construí referencias, componentes y documentación para reducir dependencia y tomar decisiones con mayor consistencia.
• En la empresa, extendí la experiencia a la web, los emails, las presentaciones, los eventos y soluciones que no podían esperar al roadmap.

Carta de recomendación, mayo de 2025. Documento completo disponible bajo solicitud.