Caso de estudio | UX/UI · Design System · SaaS · IA
Construir la base de diseño que impulsó el crecimiento del producto
Diseñé la experiencia, la marca y el sistema de diseño de una plataforma SaaS con IA que permitió escalar de la prueba de concepto al MVP.
Rol
Product Designer
UX/UI, branding, sistema de diseño y UX writing
Equipo
4 personas
1 PM · 1 Designer · 2 Devs
Duración
5 meses
Febrero — Julio 2024
Herramientas
Figma
Maze · Tailwind CSS · React
TL;DR
Entiende el proyecto en 3 claves
01
CONTEXTOJotty era un prototipo de asistente de reuniones con IA que funcionaba técnicamente, pero carecía de identidad de producto. Entré como perfil de diseño en un equipo de 2 desarrolladores y un producto sin criterio visual establecido.
02
ACCIÓNPropuse y construí un sistema de diseño desde cero (tokens, componentes y flujos) tanto en Figma como directamente en código (React + Tailwind).
03
RESULTADOEl sistema se reutilizó en 3 propuestas técnicas y 1 producto adicional. El equipo dejó de depender del designer para implementar nuevas pantallas.
Contexto
Escalar el prototipo técnico a un producto real
Jotty es el asistente de reuniones impulsado por IA desarrollado por Sciling que graba videollamadas, las transcribe y genera resúmenes editables. Al integrarme, el producto contaba con una tecnología sólida y un desarrollo ágil, pero el crecimiento se ejecutaba íntegramente desde la ingeniería. Mi papel fue transformar esa potencia técnica en una experiencia de usuario coherente, asegurando que cada avance visual fuera funcional, lógico y fácilmente implementable por el equipo.
El reto
La falta de una referencia común de diseño hacía que se tomasen decisiones directas en código que podrían acabar en inconsistencias y deuda técnica.
El objetivo
Educar en el valor del diseño a un equipo de alta capacidad técnica y construir una base que les permitiera avanzar con autonomía visual.
Estado inicial: una herramienta funcional pero sin jerarquía ni identidad.
Usuarios
Proceso
De soporte táctico a decisión estratégica
Empecé trabajando de forma reactiva, resolviendo flujos críticos y responsive para no frenar al equipo. Pero pronto identifiqué un patrón: cada nueva petición era un parche. Si queríamos escalar, no podíamos seguir diseñando excepciones, por lo que, para resolver esta situación, propuse construir un sistema de diseño y de reglas mínimo, sólido y alineado con la forma de construir el código por parte del equipo.
En un equipo donde el diseño es nuevo, la teoría no es suficiente; proponer algo así requería una justificación pragmática. En lugar de vender un "Design System" como un concepto abstracto, lo planteé como una solución de eficiencia operativa.
Estandarizar reglas nos haría más rápidos y reduciría las dudas de desarrollo en cada sprint. Y argumentarlo así y demostrar el valor que aportaba fue lo que impulsó su adopción. Este enfoque cambió la dinámica: el diseño dejó de ser un 'paso extra' para convertirse en el motor de la velocidad del equipo.
Componente de acta de reunión — sistema de diseño aplicado.
El sistema
Infraestructura de diseño: un lenguaje común entre Figma y código
Diseñé un sistema basado en la lógica del diseño atómico, donde los componentes nacían de necesidades reales del producto, no de un catálogo teórico. Las piezas eran diseñadas a demanda, al conceptualizar nuevas funcionalidades y pantallas, de manera que cualquier persona del equipo entendía por qué existia cada componente, como usarlo y sus variantes, sin que yo estuviera presente.
Para reducir fricciones, definí cada nivel tanto en Figma como directamente en código (React + Tailwind CSS), manteniendo una nomenclatura compartida y consistente de nombres de componentes, propiedades (type, size, state) y valores (primary, secondary, sm, md...). Esa taxonomía común fue lo que hizo que el sistema funcionara como lenguaje de equipo y no solo como una librería de diseño aislada.
Construcción de la cabecera de reproducción e información de la reunión con diferentes grados de componentes.
Design tokens
Establecí el ADN visual: color semántico, escalas tipográficas y espaciados definidos en el fichero de Tailwind como reflejo exacto de Figma.
Componentes base
Button, Input, Badge... diseñados con sus estados y variantes, implementados en código como par de archivos (JSX + CSS) listos para usar.
Componentes compuestos
Dropdowns, barras laterales y perfiles de usuario. Se diseñaron en diálogo constante con las restricciones de tecnología y producto, formando las piezas sobre las que se construirían las pantallas completas.
Código como fuente de verdad
A medida que el sistema se consolidó, la fuente de verdad se trasladó al código. Mantener dos fuentes habría generado la desincronización que el sistema buscaba resolver.
Producto
Balanceando el valor de usuario con el coste técnico
- Jerarquía multimediaDecisiones de layout como la jerarquía entre transcripcion y multimedia o la estructura del resumen generado condicionaba cómo el usuario entendía el valor de Jotty.
- Coste vs. valor¿Cómo equilibramos ofrecer valor al usuario con la inversión en desarrollo? Cada feature se evaluaba contra su coste técnico real antes de entrar en backlog.
- ICE scoring y PRDsCon la incorporación de la PM empezamos a trabajar por sprints con ICE scoring y PRDs, afinando el proceso de evaluar opciones y features con criterio compartido.
- Sistema bajo presiónMi foco viró hacia asegurar que el sistema de diseño aguantara el ritmo de iteración del backlog sin romperse, reutilizando componentes para evitar generar excepciones.
- Gestión de la incertidumbreEn un producto donde la IA genera el contenido, la gestión de la incertidumbre es clave. Cada estado (procesando, vacío, error, guardado, validación) se diseñó para reducir ansiedad y reforzar la sensación de control.
- Microcopy como confianzaMensajes como 'Estamos generando tu resumen, menos de 2 minutos' no son textos de relleno, sino los puntos donde el producto arriesga y gana o pierde la confianza del usuario.
Evolución de Jotty desde el prototipo de la PoC hasta el resultado final
Resultados
Eficiencia y escala demostrada
Jotty pasó de ser un prototipo técnico a una plataforma con una experiencia definida. Logramos un MVP robusto donde el equipo técnico ganó autonomía visual, pudiendo implementar nuevas pantallas manteniendo la coherencia sin necesidad de mi intervención constante.
+10
Componentes core diseñados e implementados en Figma y código
4
Propuestas técnicas conceptualizadas en Figma reutilizando el sistema de diseño
1
Taxonomía compartida que cerraba el gap entre diseño y desarrollo
Proceso
Cada nueva funcionalidad se construía reutilizando componentes en lugar de crear excepciones.
Adopción
El sistema fue tan práctico que se reutilizó para conceptualizar 3 propuestas técnicas y 1 producto adicional de Sciling.
Calidad
El MVP permitió que el producto fuese usado por usuarios beta manteniendo una experiencia coherente y alineada con la tecnología.
Escala del producto final — acta de reunión completa con sistema de diseño aplicado
Aprendizajes
Lo que aprendí
01
El contexto define el diseño tanto como el usuario
En un equipo sin experiencia previa con diseño, parte del trabajo es introducir el proceso sin imponerlo, demostrando su valor con resultados, no con presentaciones. Saber trabajar en contextos donde el diseño aún no tiene un lugar establecido es una habilidad tan importante como saber diseñar bien.
02
No siempre te piden diseñar un sistema, aunque se necesite
A veces hay que proponerlo, justificarlo y asumir que a corto plazo produce menos visibilidad inmediata. Pero su desarrollo y adopción es lo que permite que el producto pueda crecer de verdad.
03
Un sistema necesita stewardship, no solo construcción
Parte del valor del diseño va más allá de entregar el sistema. Se necesita mantenimiento activo, criterio y alguien que proteja su coherencia con el tiempo.
Hablemos
¿Tienes un proyecto?
Estoy abierta a proyectos de diseño de producto, branding y colaboraciones que tengan sentido humano. Cuéntame en qué estás pensando.