El bonus ya no puede vivir escondido

Las ultimas 24 horas en Nima Project dejaron un dato poco espectacular y bastante importante:

• no hubo commits nuevos en los repos de Nima Project dentro de ese rango;
• pero si hubo trabajo local concentrado en world-cup-porra;
• y, sobre todo, conversaciones muy precisas sobre como debe comportarse el bonus cuando el voto ya no es trivial.

Eso tambien cuenta una historia.

No todas las iteraciones maduras aparecen primero en git log.

A veces aparecen antes en tres sitios mas delicados:

• en una captura de usuario,
• en una frase que detecta una injusticia de scoring,
• y en un diff local que obliga a reordenar UX, reglas y confirmacion de cambios.

La conversacion de estas 24 horas fue mucho mas concreta que la de ayer

La conversacion util de este tramo no iba sobre nuevas competiciones.

Iba sobre una tension mucho mas incomoda: que pasa cuando el sistema sabe calcular algo, pero el usuario no entiende por que no lo ha cobrado o cuando realmente ha guardado ese cambio.

Las peticiones del chat fueron muy directas:

• en escritorio, el boton de bonus abre un panel lateral;
• una vez terminado un partido, cada campo bonus debe mostrar en verde los puntos conseguidos;
• si el resultado exacto ya incluye diferencia o porteria a cero, eso debe decirse de forma explicita;
• y si el usuario acierta porteria a cero o diferencia de goles, esos puntos deben sumar aunque no haya acertado el ganador.

La frase decisiva fue esta, en esencia:

da igual si aciertas el ganador; si tu respuesta es correcta respecto a porteria a cero o diferencia de goles, sumas esos puntos individuales

Eso parece una correccion pequena.

No lo es.

Es una redefinicion de que significa cada campo del bonus.

El problema real no era sumar puntos: era explicar de donde salen

Hasta aqui habia una tentacion muy comun en este tipo de producto:

• el usuario rellena cosas,
• el motor calcula,
• y el detalle fino queda mas o menos escondido detras del total.

El diff local de world-cup-porra va en la direccion contraria.

Ahora aparecen varias decisiones conectadas:

• desaparece el autosave de predicciones;
• aparece un flujo de abrir bonus, editar, guardar o cancelar;
• se introduce un snapshot del estado inicial para detectar cambios pendientes;
• cada campo de bonus puede ensenar su puntuacion o la etiqueta incluido en exacto;
• y el resumen de puntos separa mejor lo jugado, lo obtenido y el detalle del voto.

La idea fuerte no es "poner mas etiquetas".

La idea fuerte es esta: si el bonus influye de verdad en el resultado, no puede seguir viviendo como una inferencia privada del motor.

Tiene que salir a la superficie.

El cambio de regla mas importante fue quitar una dependencia que parecia natural

En scoring habia una dependencia implicita:

• si no acertabas el ganador,
• la diferencia de goles no contaba como bonus separado;
• y ciertos casos de porteria a cero quedaban absorbidos por una logica demasiado estrecha.

La conversacion de hoy lo revienta de forma sana.

La nueva lectura es mas limpia:

Eso cambia la semantica del formulario.

Ya no hay un unico eje jerarquico donde todo depende del ganador.

Ahora hay campos que expresan conocimiento distinto del partido y por tanto merecen puntuacion distinta.

Cuando aparece guardado manual, el mensaje es mas serio de lo que parece

Otra parte muy visible del diff es la desaparicion del autosave para esta zona.

Eso tampoco es un mero ajuste de interfaz.

Es una declaracion de producto.

Si el bonus pasa a ser:

• mas detallado,
• mas interpretable,
• mas sensible en puntos,
• y mas facil de discutir despues,

entonces guardarlo en segundo plano mientras el usuario toca controles deja de ser una ayuda.

Pasa a ser ambiguedad.

Por eso tiene sentido el nuevo flujo:

El producto esta diciendo algo bastante razonable:

editar bonus ya no es un gesto efimero; es una accion que merece confirmacion.

La UI empieza a aceptar que explicar puntos es parte del dominio

El nuevo breakdown por campo hace visible otra cosa que antes se quedaba enterrada:

• no basta con calcular bien,
• hay que dejar claro por que son +3, +1 o incluido en exacto.

Eso reduce varios tipos de friccion a la vez:

• discusiones sobre si el sistema "ha regalado" o "ha quitado" puntos,
• soporte manual para interpretar casos borde,
• y desconfianza cuando el total final no coincide con la intuicion del usuario.

Tambien aparece un detalle pequeno pero muy correcto: el resultado final no debe mostrarse como si existiera cuando el partido todavia no ha terminado.

Eso conecta con la misma filosofia.

La interfaz deja de adelantar verdades que el dominio aun no puede afirmar.

Hasta la notificacion de release deja ver el cambio de mentalidad

En local tambien aparece una nueva notificacion de release:

• explica que el guardado automatico se ha sustituido por guardar voto o guardar previa;
• anuncia que despues se puede usar Editar mientras la votacion siga abierta;
• y aprovecha para comunicar una correccion concreta en el listado de goleadores de Arabia Saudi - Uruguay.

Esa mezcla es reveladora.

No se esta notificando solo "hemos cambiado una regla".

Se esta notificando:

• como se confirma ahora la accion,
• que parte del flujo cambia para el usuario,
• y que dato de partido deja de introducir friccion en bonus.

Es decir: UX, modelo mental y datos de referencia dejan de viajar por carriles separados.

La idea fuerte de estas 24 horas: el bonus ya forma parte de la promesa publica

Durante una fase temprana, el bonus puede vivir como detalle secundario:

• un select aqui,
• una ayuda alli,
• un total al final.

Despues deja de ser sostenible.

En cuanto el usuario quiere saber:

• que ha sumado exactamente,
• que estaba incluido,
• que sigue editable,
• y cuando su cambio ha quedado realmente guardado,

el bonus deja de ser un apendice del voto.

Pasa a ser parte del contrato publico de la porra.

Lo que me llevo de este tramo

• Que no haya commits en una ventana de 24 horas no significa que no haya aprendizaje de producto; a veces el trabajo mas delicado vive primero en chat y diff local.
• Un bonus que afecta al resultado no puede depender de interpretaciones ocultas ni de jerarquias implicitas mal explicadas.
• Quitar autosave en una zona sensible puede mejorar el producto si lo que se gana es claridad sobre cuando un cambio queda confirmado.
• Mostrar puntos por campo no es decoracion; es una forma de hacer auditable la logica de scoring.
• Si exacto, diferencia y porteria a cero expresan conocimientos distintos, la interfaz tiene que dejar claro cuando puntuan por separado y cuando quedan absorbidos.

Estas no fueron 24 horas de sumar commits.

Fueron 24 horas de hacer algo mas incomodo y mas util: aceptar que el bonus ya no puede vivir escondido dentro del total. Tiene que poder verse, discutirse, editarse y entenderse como parte central del voto.

Parte de mis notas de producto y plataforma. Sigue el blog o escribeme.