Ley de Postel: tolerante con lo que recibes, estricto con lo que envías
La ley de Postel pide aceptar entradas imperfectas y enviar salidas consistentes. Qué significa en formularios, qué límites tiene y por qué se revisó.
¿Qué dice la ley de Postel?
La frase clásica es «Sé liberal con lo que aceptas y conservador con lo que envías». Se atribuye a Jon Postel, pionero de Internet, que lo escribió en las primeras especificaciones de IP y TCP a finales de los años setenta y comienzos de los ochenta. Su redacción original decía «sé conservador en lo que haces, sé liberal en lo que aceptas de otros». Los protocolos tenían que convivir con implementaciones de distintos fabricantes, y esa regla evitaba que un detalle fuera de norma rompiera la comunicación (Wikipedia, “Robustness principle”).
Laws of UX la adapta a la interacción con personas. Su versión indica que los receptores deben aceptar entradas que no cumplen el formato exacto mientras su significado sea claro, y que la flexibilidad debe tener límites definidos y retroalimentación clara (Laws of UX, “Postel’s Law”).
¿Por qué le importa a un diseñador?
Porque los formularios son el lugar donde más se castiga a la gente por escribir distinto a como el sistema espera. Un teléfono con espacios, una fecha escrita en otro orden o un correo con mayúsculas pueden bloquear un registro sin ninguna razón real. La ley de Postel te pide preguntarte si el error es del usuario o de tu regla.
En la práctica, esto significa que el sistema se encarga de convertir la entrada a lo que necesita: aceptar fechas en varios formatos, dejar que el teléfono se escriba libremente y formatearlo después, o aceptar correos con distintas estructuras válidas. Laws of UX lo plantea igual: aceptar entradas variadas, traducirlas a lo que tu sistema requiere y dar retroalimentación clara.
¿Cómo se aplica en un formulario?
Una regla práctica: tolera la forma, valida el significado.
- Acepta variantes de formato. Si el campo pide un teléfono, acepta con y sin espacios, con prefijo o sin él. Formatea después.
- No castigues por mayúsculas ni por espacios sobrantes. Recorta espacios y normaliza lo que no cambia el significado.
- Corrige cuando el resultado no cambia. Si la persona escribió «Madird», puedes sugerir «Madrid». Si cambia el dato, pregunta. Para decidir cuándo conviene prevenir un error y cuándo recuperarlo, la página sobre prevención vs. recuperación de errores te da el marco.
- Da errores claros cuando no se puede interpretar. Una frase que dice qué falta y cómo corregirlo vale más que un «formato no válido».
- Mantén la salida consistente. Lo que guardas, lo que envías a otro sistema y lo que muestras debe seguir un formato único.
Los buscadores que corrigen erratas o los navegadores que completan una URL incompleta funcionan con esta lógica.
¿Cuáles son sus límites?
La flexibilidad tiene límites, y la propia comunidad técnica lo discutió. El RFC 9413, escrito por Martin Thomson y David Schinazi y publicado por el IAB en 2023, separa tres cosas: los defectos, los ataques y la entrada inesperada. Defiende que tolerar la entrada inesperada ya no es la mejor práctica en todos los casos. Describe además la «decadencia del protocolo»: un error que se tolera se empieza a usar, y entonces todas las implementaciones tienen que copiarlo. Y concluye que ignorar una entrada defectuosa o ambigua casi siempre es la solución equivocada (RFC 9413).
La propuesta del documento es mantener los protocolos de forma activa: revisar las especificaciones junto con las implementaciones para reducir la ambigüedad con el tiempo, en lugar de depender de la tolerancia (IAB, “RFC 9413 on maintaining robust protocols”). Wikipedia recoge también críticas de seguridad, como un trabajo de 2018 que mostró que el principio podía explotarse en el protocolo de enrutamiento de Tor.
Para diseño, la lección es parecida: tolerar no es lo mismo que adivinar. Una contraseña que se «interpreta» de forma laxa, un importe que se redondea sin avisar o un correo que se corrige a otro dominio son casos en que el sistema esconde un problema en lugar de resolverlo.
Ejemplo
Ejemplo ilustrativo: un formulario de pago pide la fecha de vencimiento de la tarjeta en formato MM/AA. Una persona escribe «3/27». Un formulario estricto la rechaza con «formato no válido». Uno tolerante lo interpreta como marzo de 2027, lo muestra formateado como «03/27» y pide confirmación visual antes de enviar. Ahora imagina que escribe «27/3». Ahí la interpretación no es segura: el formulario muestra un error claro que dice que el mes va primero. La regla es la misma, pero el sistema solo adivina cuando el significado no deja dudas.
¿Cuándo NO conviene aplicarla?
- En datos sensibles o críticos. Contraseñas, importes y identificadores no deben corregirse en silencio.
- Cuando la corrección cambia el significado. Si «Ana Lopez» puede ser «Ana López» o una persona distinta, no la cambies sin preguntar.
- Cuando el sistema necesita un formato exacto. Un código de verificación o un número de cuenta no admite interpretación.
- Como excusa para no definir reglas. Tolerar sin reglas claras es improvisar, no diseñar.
Errores comunes
- Rechazar entradas válidas por un espacio o una mayúscula.
- Corregir datos sin avisar a la persona.
- Mostrar errores genéricos que no dicen cómo arreglarlos.
- Guardar el dato en un formato y mostrarlo en otro.
- Confundir tolerancia con falta de validación.
Cómo empezar mañana
Abre el formulario con más abandono de tu producto y lista los campos que rechazan una entrada. Para cada uno, pregúntate si el error es real o de formato. Si es de formato, acepta la variante y normalízala. Si es real, deja un mensaje que diga qué falta. Revisa también cómo se guarda el dato y cómo se muestra. Si la validación te preocupa en el momento, el texto sobre tiempo de validación de formularios te ayuda a decidir cuándo avisar. Y para los campos que formatean mientras escribes, mira los peligros del input masking. Si el aviso de error aparece después de enviar, revisa también cómo se muestra en notificaciones y toasts, porque un mensaje que se va solo no sirve para corregir un dato.