LibroFirmas.es

LibroFirmas.es es un libro de firmas digital para eventos. En lugar de un cuaderno que circula por las mesas, cada invitado entra desde su móvil —con un código QR o con un enlace que alguien le pasa por WhatsApp— y deja su dedicatoria: texto, una fotografía, un audio, o las tres cosas.

No es un encargo que el estudio entregase a un cliente. Lo construimos nosotros y lo operamos nosotros: sus usuarios, sus pagos y sus decisiones de producto son nuestros.

El producto lo usa gente que no ha elegido usarlo. Un invitado se encuentra un código QR en mitad de una celebración y decide en unos segundos si aquello merece la pena. No hay tutorial ni nadie a quien preguntar.

Eso obliga a resolver cosas que un sitio de presentación nunca tiene que resolver. Que funcione al primer intento en cualquier móvil y en cualquier navegador. Que quien organiza el evento pueda montarlo y dejarlo listo sin ayuda técnica. Que lo que entra se vea durante la fiesta y no al día siguiente. Y que alguien pueda administrar lo que aparece, porque el contenido lo suben terceros.

La decisión que ordena todas las demás no es haber puesto un QR: es haber juzgado el producto por la distancia entre el evento y la participación. Un invitado no debería tener que aprender nada, instalar nada ni entender cómo está hecho aquello. El código QR y el enlace por WhatsApp son dos formas de la misma decisión — que del salón al teléfono no haya más que un gesto.

El muro en tiempo real tampoco es una funcionalidad suelta. Que las dedicatorias puedan verse durante la propia celebración cambia lo que el producto es: deja de ser un archivo que alguien abrirá al día siguiente y pasa a ser algo que ocurre dentro del evento. Esa diferencia decide qué hay que optimizar, y lo que entra tiene que entrar bien y rápido antes que cualquier funcionalidad añadida.

Aceptar texto, fotografía y audio es aceptar que el contenido es imprevisible. No son piezas que prepara un diseñador: llegan de móviles distintos, de navegadores distintos y con orientaciones distintas. Diseñar para eso, y no para el caso ideal, es lo que separa un producto que aguanta un evento real de uno que sólo funciona con los archivos de prueba.

La última decisión es la menos vistosa: operar el producto forma parte de construirlo. La autenticación, los pagos, la administración y la medición no son anexos que se añaden al final — son producto tanto como el muro.

El primer despliegue no fue el final del trabajo. Fue el momento en que empezaron a aparecer los problemas de verdad.

El ejemplo más claro son las fotografías. Una imagen subida desde un móvil no llega como se ve en la pantalla de ese móvil: trae metadatos EXIF de orientación que cada navegador interpreta a su manera, y la misma foto puede acabar girada en un sitio y derecha en otro. No es algo que se vea diseñando. Orientación de imagen, tratamiento y compatibilidad entre navegadores fueron trabajo real.

El muro en tiempo real y la experiencia móvil son del mismo tipo: no basta con que funcionen en el escritorio de quien los programa, tienen que funcionar en el móvil de cada invitado. Con los pagos ocurre algo parecido — integrar Stripe es el principio; lo que pide trabajo después son los casos que no salen bien.

Autenticación, administración y medición son parte del mismo trabajo. Construir, mirar cómo se usa, corregir, y volver a mirar.

Operar un producto propio enseña cosas que un encargo no enseña, porque las consecuencias de cada decisión técnica las pagamos nosotros.

La primera es que un producto real encuentra problemas que ninguna maqueta revela. La orientación de una fotografía, un navegador que se comporta distinto: nada de eso aparece hasta que lo usa alguien que no eres tú.

La segunda es que quitar pasos suele valer más que añadir funcionalidades. En algo que se usa en mitad de una celebración, cada paso intermedio es una ocasión más de que alguien lo deje a medias.

La tercera es que el móvil no es una adaptación posterior cuando el producto se usa desde un evento, y que lo que suben los usuarios son datos imprevisibles, no piezas controladas. Se diseña para lo que llega, no para lo que preferirías que llegara.

Y la cuarta es la que más se nota después, trabajando para clientes: la autenticación, los pagos, la analítica y la administración no son extras del final del proyecto. Son producto. Eso es lo que traemos a cada web que hacemos.