Ejercicios de diseño de producto

Cómo se construyó la solución.

1. 01

   Auditoría de accesibilidad de referentes

   Revisé apps de salud existentes con criterios WCAG 2.1 AA: contraste, tamaño de objetivo táctil y lectura por voz. La mayoría fallaba en contraste de texto secundario y en botones por debajo de 44px.

2. 02

   Flujos por rol, no por función

   En lugar de un único flujo de 'registrar toma', diseñé dos rutas distintas: una simplificada al máximo para el paciente y un panel de seguimiento para el cuidador, con la misma base de datos pero jerarquías visuales distintas.

3. 03

   Sistema tipográfico escalable

   Definí una escala tipográfica con un tamaño base mayor de lo habitual (18px) y modo de alto contraste como variante de tema, no como ajuste oculto en configuración.

4. 04

   Pruebas de bajo coste con papel y clic

   Antes de construir en Figma de alta fidelidad, validé la secuencia de registro de medicación con prototipos en papel para detectar pasos innecesarios.

El resultado es un sistema de interfaz con objetivos táctiles grandes, una única acción principal por pantalla y confirmaciones visuales y textuales redundantes. Como ejercicio conceptual, sienta una base de componentes reutilizable para cualquier producto de salud digital centrado en accesibilidad real, no solo en cumplir un checklist.

Cómo se construyó la solución.

1. 01

   Partir del ritual, no del menú

   El moodboard inicial no salió de la carta sino del ritual de sentarse a comer: luz cálida, texturas de madera y mantel, tipografía con carácter pero legible en carta impresa y en pantalla.

2. 02

   Un sistema tipográfico de dos voces

   Una serif con personalidad para nombre y titulares, y una sans neutra para toda la información funcional (horarios, precios, formularios), evitando que la carta se volviera ilegible por exceso de estilo.

3. 03

   Reserva en tres pasos, sin cuenta obligatoria

   Diseñé el flujo de reserva para que se completara sin registro: fecha, comensales, contacto. Cualquier paso adicional se marcó como opcional, priorizando la conversión sobre la recogida de datos.

4. 04

   Web mobile-first pensada para decidir rápido

   La mayoría de quien busca restaurante lo hace desde el móvil y con prisa: la jerarquía prioriza fotos del ambiente, ubicación y botón de reserva por encima de la historia de la marca.

Se definió un sistema de marca aplicable a carta, señalética y digital, junto con una web responsive centrada en la conversión de reservas. Como ejercicio conceptual, demuestra cómo el diseño de marca y el diseño de producto pueden trabajar juntos en un mismo flujo de decisión del usuario.

Cómo se construyó la solución.

1. 01

   Filtro por capacidad, no por nivel

   Sustituí el selector de 'nivel' por un filtro de capacidad física: impacto en articulaciones, necesidad de apoyo, rango de movimiento requerido. El catálogo de ejercicios se reorganizó alrededor de estos ejes.

2. 02

   Demostración antes que texto

   Cada ejercicio se explica primero con una demostración visual clara y después con instrucciones de texto cortas, pensando en personas que entrenan con el sonido apagado.

3. 03

   Botones de pausa y ajuste siempre visibles

   Durante una rutina, los controles para pausar, bajar intensidad o saltar un ejercicio están siempre en pantalla, sin necesidad de gestos ocultos, algo habitual en apps de fitness que prioriza la estética sobre el control real del usuario.

4. 04

   Sistema de iconografía propio

   Diseñé un set de iconos de movimiento coherente para comunicar tipo de ejercicio, articulación implicada y nivel de impacto de un vistazo, reduciendo la dependencia del texto.

El resultado es un sistema de interfaz centrado en dar control real durante el entrenamiento y en clasificar contenido por capacidad física en lugar de por etiquetas genéricas de nivel. Un planteamiento conceptual que pone la accesibilidad motriz en el centro del producto, no en un anexo.

Cómo se construyó la solución.

1. 01

   Mapear cómo la gente planifica hoy

   Antes de diseñar pantallas, mapeé el proceso actual: capturas de pantalla, notas sueltas, mensajes reenviados. El patrón común era la fragmentación, no la falta de herramientas.

2. 02

   El itinerario como línea de tiempo, no como lista

   En vez de una lista cronológica plana, diseñé el itinerario como una línea de tiempo horizontal por día, con los huecos vacíos tan visibles como las reservas confirmadas.

3. 03

   Añadir reservas por reenvío, no por formulario

   El flujo de alta prioriza reenviar un email de confirmación o pegar un enlace, extrayendo los datos clave automáticamente, en vez de obligar a rellenar un formulario largo para cada reserva.

4. 04

   Vista compartida para viajes en grupo

   Diseñé una vista de solo lectura pensada para compartir el itinerario con acompañantes de viaje sin darles acceso de edición, un caso de uso que apareció de forma repetida en las entrevistas.

El resultado es un sistema de planificación visual centrado en reducir la carga cognitiva de organizar un viaje complejo. Como ejercicio conceptual, prioriza la claridad temporal del itinerario por encima de replicar las funciones de un buscador de reservas.

Cómo se construyó la solución.

1. 01

   Comparar antes de elegir, en una sola pantalla

   El punto de partida es una pantalla que compara tiempo, esfuerzo físico y modo de transporte de dos o tres rutas a la vez, en lugar de obligar a entrar en cada opción por separado.

2. 02

   Rutas combinadas como primera clase

   Diseñé rutas mixtas (bici + metro, caminar + bus) como resultado principal del buscador, no como una combinación manual que el usuario tiene que armar él mismo.

3. 03

   Iconografía de esfuerzo, no solo de tiempo

   Cada tramo de ruta se comunica con iconos de modo de transporte y una indicación simple de esfuerzo físico, pensando en quien decide su trayecto según cómo se siente ese día, no solo según el reloj.

4. 04

   Mapa legible en exteriores

   Se definió una paleta de alto contraste para las líneas de ruta sobre el mapa, pensada para leerse bien con luz solar directa desde un móvil en la calle.

El resultado es un sistema de navegación que integra varios modos de transporte en una sola decisión y comunica el coste real —de tiempo y de esfuerzo— de cada ruta. Un ejercicio conceptual centrado en hacer que la opción sostenible compita en comodidad, no solo en intención.

Cómo se construyó la solución.

1. 01

   Editor primero, chat después

   En vez de un chat como interfaz principal, diseñé un editor de texto como espacio central, con la IA apareciendo como sugerencias contextuales sobre el propio contenido.

2. 02

   Sugerencias por partes, no reescrituras completas

   Cada intervención de la IA se limita a un fragmento (un párrafo, una estructura, un titular alternativo), permitiendo aceptar, editar o descartar sin perder el resto del texto.

3. 03

   Trazabilidad de cada cambio

   Diseñé un historial visual simple que distingue qué partes del texto ha tocado la IA y cuáles son originales del usuario, para mantener la confianza en el proceso.

4. 04

   Modos de intervención explícitos

   La persona usuaria elige de forma explícita qué tipo de ayuda pide —estructurar, resumir, dar tono— en vez de recibir una reescritura genérica de todo el texto.

El resultado es un sistema de interfaz que trata la IA generativa como un conjunto de herramientas editoriales puntuales, no como un generador de textos cerrado. Un ejercicio conceptual alineado con explorar cómo los modelos de lenguaje pueden apoyar procesos creativos sin sustituir el criterio de quien escribe.