INTRODUCTION
Un calendario puede ser una respuesta preciosa a la pregunta equivocada. Recordar una fecha de nacimiento, copiar una fecha de un documento y elegir una cita producen respuestas que parecen iguales. Pero el trabajo es diferente. Tratar esas tareas como una única decisión de componente obliga a la persona a adaptarse a la interfaz.
Antes de elegir un control, resuelve tres decisiones de producto: de dónde sale la respuesta, qué precisión necesita y qué compromiso genera. Así diseño y desarrollo comparten un criterio. También aparecen preguntas que ningún calendario pulido puede resolver.
Empieza por el origen de la respuesta
Piensa en qué está mirando la persona cuando llega al campo. Puede conocer la respuesta, tener un documento al lado o necesitar examinar opciones disponibles. Una fecha recordada no debería exigir recorrer meses de pantallas. Para una cita, en cambio, ayuda ver qué fechas son posibles.
El patrón de fechas de GOV.UK distingue estas tareas. Recomienda campos de fecha para fechas recordadas y un formato que coincida con el documento cuando se copia desde él. Es una razón práctica para definir la tarea antes de uniformar todos los campos.
En un servicio ficticio de reparación de equipos, la fecha de compra y la de recogida aparecen en el mismo formulario. El cliente copia la primera de un recibo y elige la segunda entre visitas disponibles. Un tratamiento visual único puede parecer coherente mientras dificulta ambas tareas. La coherencia debe ayudar a entender la interacción; no exige convertir preguntas distintas en la misma.
Decide cuánta certeza necesita el servicio
Exigir día, mes y año puede fabricar precisión. Si alguien solo recuerda el mes, obligarle a indicar un día invita a adivinar. Esa suposición puede circular después por informes como un dato fiable. La interfaz ha cambiado silenciosamente el significado de la información.
Pregunta qué decisión posterior depende del detalle que falta. Si basta el mes para dirigir una solicitud, pide el mes. Si la fecha exacta es imprescindible, explica dónde encontrarla y qué hacer cuando no se pueda recuperar. No ofrezcas una respuesta aproximada que el servicio sea incapaz de procesar.
Volvamos a la reparación. Evaluar una garantía puede exigir una prueba de compra; una consulta inicial quizá solo necesite una estimación de la antigüedad del objeto. El equipo de producto debe resolver esa diferencia con quien gestiona el servicio. Hacer el campo opcional y esperar que el resto funcione no sustituye esa decisión.
Separa una fecha de una cita
Una fecha puede describir un día sin especificar un instante. Una cita añade hora y lugar o zona horaria. Mezclar esos significados genera sorpresas: el cliente cree haber elegido la hora del taller y la confirmación refleja la configuración de su dispositivo.
MDN documenta que el campo nativo datetime-local no incluye una zona horaria. Elegir ese control no termina el diseño de la reserva. El producto todavía debe establecer a qué zona pertenece la cita y mostrar esa interpretación donde resulte necesaria.
Para el servicio ficticio, una confirmación podría indicar fecha, hora y nombre del lugar de recogida. Para una sesión remota, puede hacer falta identificar expresamente la zona horaria. Escribe primero la confirmación y comprueba después que la entrada proporciona todo lo necesario para que sea cierta. Evita añadir etiquetas técnicas a una pregunta que solo necesita una fecha.
Un formulario sencillo puede ser mejor
Hay una objeción razonable a construir varios controles a medida: más variantes implican más mantenimiento, pruebas y posibilidades de comportamiento incoherente. Un producto pequeño no debería encargar una interfaz compleja de planificación para unas pocas fechas.
Empieza con controles nativos conocidos y etiquetas claras cuando sirvan a la tarea. Introduce un calendario cuando ver la relación entre fechas ayude a elegir. El objetivo es un conjunto pequeño de patrones con una finalidad y un significado documentados, no un componente nuevo para cada pantalla.
Aplica la misma precisión a la validación. Una fecha imposible, una cita no disponible y una respuesta obligatoria ausente necesitan explicaciones diferentes. Conserva las partes válidas del trabajo e indica qué se puede cambiar. Un borde rojo alrededor de tres casillas apenas ayuda a localizar el problema real.
Revisa la respuesta completa
Ensaya tres recorridos cortos: una fecha antigua conocida, una fecha copiada y una cita futura. Usa un teléfono y un teclado, y revisa después la pantalla de comprobación y la confirmación. Pide a una persona que explique qué cree el servicio que ha elegido, sin interpretar la interfaz por ella.
Antes de lanzar, escribe una frase para cada campo: «Necesitamos esta fecha de esta fuente, con esta precisión, para esta decisión». Si no queda clara, el componente no es el problema pendiente. Explora más decisiones prácticas de producto en el journal de Blanche.
Fuentes principales consultadas el 10 de noviembre de 2026. Los ejemplos son hipotéticos; el artículo presenta un método de diseño, no el anuncio de un producto nuevo.