Construir Nuri para los días en que algo falla

Estas dos semanas no salieron según lo previsto

Teníamos un plan para las dos últimas semanas. Entonces llegaron esas dos semanas.

Queríamos dedicar ese tiempo a pulir la app, empezar a distribuirla e incorporar a más usuarios. En lugar de eso, pasamos buena parte del tiempo reaccionando a problemas en Bitcoin, Lightning y distintas vías de pago.

Sinceramente, fue agotador.

No porque todos los problemas fueran catastróficos. Aún estamos empezando y el número de usuarios afectados era manejable. Pero parecía el día de la marmota: arreglábamos una cosa, cambiaba otra, luego dejaba de funcionar una alternativa y después surgía algo más que necesitaba atención.

Mi primera reacción fue de frustración. Pero, después de pensarlo, la lección más importante se hizo evidente.

Esto volverá a pasar.

I must say I feel exhausted after these two weeks.

Emin Mahrt · De la grabación original

Este es el entorno en el que construimos

Nuri conecta muchos sistemas financieros distintos. La banca, las tarjetas, Bitcoin, Lightning, las monedas locales y las infraestructuras de pago se comportan de forma diferente. Algunas partes son nuestras. Otras nos conectan con infraestructura externa. Cualquiera de ellas puede cambiar, entrar en mantenimiento o dejar de funcionar temporalmente.

Todo el mundo en este sector, nosotros incluidos, trabaja en sistemas complejos. Los cambios y las interrupciones forman parte de ese trabajo. Elegimos reunir estos sistemas, así que la experiencia que tienen los usuarios cuando algo cambia es responsabilidad nuestra.

Nuestro trabajo no es fingir que todas las piezas funcionarán perfectamente para siempre. Nuestro trabajo es asegurarnos de que Nuri siga siendo útil cuando una de ellas falle.

if you're building a puzzle with many moving parts, of course, those moving parts are going to work, going to not work, going to break.

Emin Mahrt · De la grabación original

Una alternativa tiene que funcionar cuando hace falta

El momento más frustrante no fue que una función dejara de funcionar. Eso puede pasar.

Lo frustrante fue descubrir que una alternativa ya no estaba disponible justo en la situación en la que los usuarios la necesitaban.

Eso nos enseñó algo muy sencillo: una alternativa que solo funciona en condiciones normales no es una gran alternativa.

Tenemos que seguir eliminando puntos únicos de fallo siempre que podamos. A veces eso significa añadir otra vía. A veces significa dar a los usuarios una forma de recuperarse o de salir sin depender de nosotros. A veces solo significa separar dos funciones que parecen similares, pero fallan por motivos completamente distintos.

Bitcoin y Lightning son un buen ejemplo. Para muchos usuarios pueden parecer dos versiones de lo mismo. Técnicamente, son sistemas muy distintos, con diferentes ventajas e inconvenientes y diferentes formas de fallar. Presentarlos como un único saldo integrado puede quedar más limpio, pero también significa que un problema de Lightning puede hacer que toda la experiencia con Bitcoin parezca rota.

Por ahora, separarlos es más honesto y más útil. Bitcoin puede seguir funcionando cuando Lightning no está disponible. Lightning puede mostrar claramente su estado actual. Los usuarios no deberían tener que entender el motivo técnico. Solo necesitan saber qué funciona, qué no y qué pueden hacer a continuación.

Nos esforzamos demasiado por ocultar la maquinaria

Durante mucho tiempo quise que Nuri ocultara toda la complejidad.

Ese sigue siendo el objetivo en muchos sitios. Nadie debería tener que entender de nodos, liquidez, encaminamiento de pagos o proveedores de infraestructura para enviar dinero.

Pero ocultar la complejidad no puede significar ocultar la realidad.

Si una vía no está disponible temporalmente, la app debería decirlo. Si algo está en mantenimiento, debería parecer que está en mantenimiento. Si una moneda está disponible como vía de pago, pero no como saldo, la interfaz debería dejar clara esa diferencia.

Antes intentábamos evitar mensajes como «no disponible temporalmente». Parecían técnicos y poco amables. Visto ahora, eso creó una experiencia peor. Un botón que parece disponible, pero falla después de pulsarlo, es mucho más frustrante que un botón en gris con una explicación clara.

Esto cambia nuestra forma de pensar en la pantalla principal de Nuri. No solo debería mostrar dónde está tu dinero. También debería mostrar qué puedes hacer con él en este momento.

Puede que tengas dinero en euros y varias formas de usar esos euros: pagos con tarjeta, transferencias bancarias o convertirlos a otra moneda. Algunas infraestructuras de pago ni siquiera necesitan tener su propio saldo. Son simplemente otra forma de enviar o recibir dinero.

Al mismo tiempo, nunca debemos mostrar el mismo dinero dos veces. Si tu tarjeta y tu cuenta bancaria usan el mismo saldo subyacente, mostrar esa cantidad en ambos sitios puede hacer que parezca que tienes el doble del dinero que realmente tienes.

Puede que la primera versión no sea bonita, pero tiene que ser clara.

El soporte debería saber lo mismo que la app

Esta semana también cambió mi forma de entender el soporte.

El soporte no debería ser un sistema separado con una lista de funciones desactualizada. Debería entender la misma Nuri que está viendo el usuario.

Si una vía no está disponible, el soporte debería saberlo de inmediato. Si se ha desactivado una función, nuestro agente de soporte no debería recomendarla. Si alguien pregunta por qué no puede pagar una factura de Lightning, el soporte debería poder ver si la vía funciona, explicar la situación actual y sugerir una alternativa disponible.

Aquí es donde nuestro trabajo con MCP se vuelve práctico.

MCP suena técnico, pero la idea básica es sencilla: queremos que todas las capacidades de Nuri estén disponibles a través de una interfaz limpia que puedan entender tanto la app como los agentes.

El MCP de Nuri debería contener las funciones que están disponibles de verdad en Nuri. Las funciones experimentales deberían estar en otro lugar hasta que estén listas.

Ahora mismo, esa separación no siempre está clara. Tenemos experimentos, funciones de la app y servicios independientes demasiado juntos. Tenía sentido cuando avanzábamos rápido y probábamos ideas. Tiene menos sentido ahora que queremos que los agentes den soporte a usuarios reales.

Cuando algo pase a estar disponible en Nuri, el agente de soporte debería entenderlo. Cuando algo desaparezca de la app, también debería desaparecer de las acciones disponibles para el agente. La app, el soporte y la infraestructura deberían describir la misma realidad.

No vamos a esperar a que todo sea perfecto

Podemos pasar meses diseñando la alternativa perfecta para cada fallo posible. Luego lanzamos y descubrimos que los usuarios están confundidos por algo completamente distinto.

Necesitamos usuarios reales.

Necesitamos que la gente abra Nuri, intente usarla y nos diga dónde se atasca. No porque tenga una teoría sobre nuestra interfaz, sino porque quería hacer algo y no pudo.

Ese feedback es más útil que diez opiniones internas.

Un ejemplo surgió al separar las tarjetas y las transferencias bancarias. Desde el punto de vista técnico, juntarlas puede parecer lógico porque quizá compartan un saldo. Pero los usuarios preguntaban una y otra vez dónde estaba su IBAN. Abrían la pantalla de la tarjeta, veían una tarjeta y dejaban de buscar. No esperaban que las transferencias bancarias estuvieran escondidas allí.

Los usuarios no necesitan saber por qué agrupamos dos cosas en un principio. Solo saben que no pudieron encontrar lo que necesitaban.

Así que avanzaremos más rápido, aunque las pantallas y los flujos aún estén sin pulir. Después veremos dónde tiene problemas la gente y mejoraremos esas partes. Algunas cosas no tendrán un aspecto perfecto y algunos experimentos fallarán. Una idea puede tener sentido en una reunión y parecer equivocada en cuanto alguien la pruebe.

Preferimos aprenderlo ahora.

it's okay that things break it's okay that they don't look good we just react on it and basically make the best out of it

Emin Mahrt · De la grabación original

Lo que vamos a hacer ahora

Seguiremos mejorando la app, pero también empezaremos a conseguir que la use más gente. La distribución no puede seguir siendo la tarea que posponemos cada vez que algo falla.

Estamos separando funciones para que una vía no disponible no perjudique al resto de la experiencia, añadiendo información de estado más clara y ordenando el MCP de Nuri para que coincida con la app. Soporte debería saber qué funciones están disponibles. Una mejor monitorización nos ayudará a encontrar los problemas antes de que se conviertan en largas conversaciones con soporte.

Para Lightning, estudiaremos las opciones disponibles sin precipitarnos y acabar atados a otra dependencia permanente.

Hay varios pasos posibles. Podemos admitir intercambios normales entre Bitcoin y Lightning, investigar versiones más rápidas más adelante, evaluar otros enfoques sin custodia o seguir mejorando nuestra integración actual cuando estén disponibles las capacidades necesarias.

No tenemos que tomar hoy todas las decisiones.

Bitcoin puede seguir siendo útil sin fingir que todos los casos de uso de Lightning ya están resueltos. Lightning es difícil y el sector en general todavía está intentando resolver algunos problemas complicados. Preferimos ser honestos al respecto antes que forzar una experiencia que parezca integrada, pero se vuelva confusa cuando algo cambie.

El mismo principio se aplica más allá de Bitcoin. Si la vía de una moneda local entra en mantenimiento, el resto de Nuri debería seguir funcionando. Si un servicio de tarjetas no está disponible, los usuarios deberían poder seguir encontrando sus opciones de transferencia bancaria. Si una función es experimental, no debería aparecer discretamente como si estuviera lista para producción.