Dots. Memories
Dots. Memories es una app para guardar y revivir recuerdos, con más de cinco millones de usuarios en iOS y Android. Dotbook convierte esos recuerdos en un libro físico, con códigos QR que llevan de vuelta a los vídeos: la capa que diferencia a Dots de una galería más.
- Ámbito
- Síntesis de research y tests
Diseño UX y UI
Análisis de uso
Entrega a desarrollo - Rol y periodo
- Product Designer
2025 — 2026 - Equipo
-
-
- Herramientas
- Figma
Microsoft Clarity
Claude Code y MCP de Figma
GitHub
Punto de partida
Hacemos miles de fotos que quedan perdidas en la galería
Cuando comenzó el proyecto, Dots ya tenía más de cinco millones de usuarios. Lo que aún no existía era Dotbook: convertir los recuerdos guardados en un libro físico.
El equipo de producto realizó el research que sirvió de base para nuestro trabajo. Sus hallazgos apuntaban a dos barreras principales: demasiadas fotos y poco tiempo para organizarlas, y una falta de urgencia que hacía que muchas personas no llegaran a crear el producto que querían.
A partir de estos insights, diseñamos, testamos e iteramos el flujo de creación de Dotbook.
Falta la pieza de datos del research.
La del Figma todavía es la de otro proyecto.
«Hacemos más y más fotos pero no tenemos ningún recuerdo.»
Madre de un niño de 12 años
«Me gustaría hacerlo pero no lo hago. Todo está en mi móvil.»
Madre de un niño de 12 años
«Tengo un año posponiendo lo de imprimir un álbum. Se me hace bola. Es algo que me digo todos los días.»
Madre de un niño de 1 año
Dirección estratégica
Convertir esos recuerdos en una historia que se pueda conservar
El research de producto dejó tres hallazgos claros. No eran problemas de interfaz, sino de hábitos: cómo se hacen las fotos, quién debería verlas y qué es lo que de verdad emociona al volver a ellas. El diseño partió de ahí.
Hacemos miles de fotos.
Casi nunca volvemos a ellas.
Seleccionar fotografías era la parte más pesada del proceso. Mucha gente había empezado álbumes antes y no los había terminado.
Qué decidimos: generar el Dotbook automáticamente en vez de pedirle al usuario que seleccionara y compusiera.
Los padres quieren controlar quién accede a los recuerdos de sus hijos.
La privacidad se convirtió en una parte fundamental de la experiencia.
Qué decidimos: un panel de permisos con aprobación de invitados, bloqueo de capturas y un mensaje explícito de seguridad en la propia pantalla.
Lo que emociona no es la foto. Es la voz.
El valor emocional no estaba en la imagen, sino en lo que ocurrió, quién estaba allí y lo que alguien dijo. Esto no salió de que nadie lo dijera solo: salió de enseñar el concepto de QR y voz y medir la reacción.
Qué decidimos: llevar el vídeo al papel con un QR sobre la página, en vez de imprimir un fotograma.
Qué descartamos: una interfaz nueva con vista de galería, porque esa era la experiencia que ya había en la app. Queríamos una versión MVP que aprovechase los recursos existentes para acercarnos a un reproductor en el que el foco principal fuese el contenido.
Experiencia físico-digital al añadir vídeos sobre soporte físico
Prototipo
Convertir recuerdos en un libro sin convertirlo en un editor
Querían el libro.
No querían hacer el libro.
Guardar recuerdos digitalmente era solo una parte de la experiencia. Queríamos que Dots pudiera convertir esos recuerdos en algo físico: un libro que pudieras tocar, guardar y volver a abrir años después.
Crear un fotolibro tradicional requiere seleccionar, ordenar, recortar, componer y decidir qué entra y qué no. Queríamos convertir los recuerdos digitales en un libro físico sin convertir la creación en un editor complejo.
El flujo se diseñó, testeó e iteró en cuatro rondas con 13 usuarios. Cada ronda partía de la anterior: empezamos detectando problemas de comprensión y estructura y terminamos afinando detalles de copy, nomenclatura y estados.
Diseñar con restricciones
El producto físico introducía restricciones invisibles para el usuario
Había que conectar dos mundos con reglas muy diferentes. En lugar de trasladar esa complejidad a la interfaz, la convertimos en reglas de producto. El objetivo era que el usuario pudiera crear un libro sin tener que entender cómo se fabrica.
Generar automáticamente no significaba perder el control
El Dotbook se generaba automáticamente, pero añadimos edición para que el usuario pudiera personalizar fotos y textos.
La producción empezaba antes de imprimir
El usuario elegía las fotos y las páginas se generaban automáticamente, adaptándose a los pliegos de 4 páginas que exigía el proveedor.
Lo que funciona en pantalla no siempre funciona en papel
Detectamos imágenes con resolución insuficiente para impresión y añadimos un aviso antes de producir el libro.
No toda restricción debía convertirse en un bloqueo
La portada era necesaria, pero hacerla obligatoria generaba fricción: este paso concentró un gran porcentaje de abandono y replanteamos cuándo pedirla.
Análisis
Pedir contenido cuesta más que pedir una decisión
Dos embudos de Microsoft Clarity sobre el flujo publicado, del 27 de mayo al 24 de agosto de 2026. Lo que en los tests era una intuición aquí tiene escala: los pasos donde el usuario solo elige entre opciones cerradas pierden un 4 % de media; los pasos donde tiene que aportar algo (elegir fechas, escribir un título, recortar una foto), entre un 14 % y un 33 %.
La portada llegaba vacía. Por resolución y tamaño de impresión no podíamos usar la foto que el usuario había elegido, así que le pedíamos otra; y título y subtítulo tenían restricciones de longitud. Eran decisiones razonables para diseño y desarrollo. En uso real, eran el punto de abandono.
Movimos la personalización al final, cuando el usuario ya podía previsualizar su Dotbook completo y entendía qué estaba haciendo. La elección de portada pasó a mostrarse con un mockup hecho con sus propias fotos, no con una foto de producto genérica. Y quitamos las restricciones de la portada: título, subtítulo y foto salían rellenos por defecto con los datos que ya teníamos del álbum.
Aprendizajes
Lo que considerábamos importante no siempre lo era para el usuario
Trabajé en un producto que se mueve entre dos mundos: una experiencia digital que debe sentirse sencilla y un producto físico lleno de restricciones que el usuario no debería tener que entender.
No siempre se trata de dar más opciones, sino de introducirlas en el momento adecuado.
Lo que nosotros considerábamos importante no siempre era lo que el usuario consideraba importante.