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. Cuando me incorporé, la tecnología funcionaba y el desarrollo avanzaba rápido. Pero las decisiones de UI se tomaban sobre la marcha directamente en código, y esa inconsistencia podía lastrar la experiencia y generar deuda técnica.
Mi desafío no era solo mejorar la interfaz y la experiencia, sino educar en el valor del diseño a un equipo de alta capacidad técnica que no priorizaba la parte visual del producto. Cada decisión estaba condicionada por esta realidad y debía ser pragmática, lógica y, sobre todo, implementable.
Estado inicial: una herramienta funcional pero sin jerarquía ni identidad.
Usuarios
Profesionales con reuniones frecuentes que necesitan capturar y reutilizar información sin esfuerzo.
Dos developers que necesitaban una base de diseño para avanzar con autonomía y dejar de tomar decisiones de UI sin criterio compartido.
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.
Pantalla de subida de archivos a Jotty · Noviembre 2023
Pantalla principal del producto en una nueva iteración de diseño · Noviembre 2023
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.
De átomos a organismos: un ecosistema vivo y sincronizado con el código.
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
Conforme el producto crecía, las preguntas trascendieron la interfaz: ¿Cómo priorizamos la jerarquía entre transcripción y multimedia? ¿Cómo equilibramos entre ofrecer valor al usuario y la inversión en desarrollo?.
Con la incorporación de la PM, se afinó el proceso de evaluar las opciones y features. Empezamos a trabajar por sprints con ICE scoring y PRDs. Mi foco viró hacia asegurar que las decisiones de diseño fueran estratégicas y que el sistema de diseño aguantara el ritmo de iteración del backlog sin romperse.
En un producto donde la IA genera el contenido, la gestión de la incertidumbre es clave y con ello, el microcopy y los estados. Cada estado (procesando, vacío, error, guardado, validación) se diseñó para reducir ansiedad, orientar sin frustrar y reforzar la sensación de control, visibilizándolos constantemente en la interfaz para notificar al usuario. Mensajes como 'Estamos generando tu resumen, menos de 2 minutos' o 'Guardado automaticamente' al editar un resumen no son textos de relleno, sino puntos donde el producto arriesga y gana o pierde confianza.
Home — dashboard con reuniones y actas pendientes de revisión
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.