Antes de pedir diseño UI, responde estas cinco preguntas
Pedir pantallas parece una forma rápida de avanzar. Pero si el equipo aún no puede explicar qué hará cada persona, cómo terminará su tarea y qué ocurrirá cuando algo falle, el diseño llenará esos vacíos con suposiciones que después pueden convertirse en retrabajo.
Una interfaz puede ayudar a explorar una idea aunque todavía existan preguntas abiertas. La dificultad aparece cuando se espera que el diseño UI resuelva por sí solo decisiones sobre el producto: qué necesidad atender, cómo funcionará el servicio y qué resultado recibirá quien lo use. Antes de encargar las pantallas, responde estas cinco preguntas. No necesitas conocer todos los detalles, pero sí distinguir lo que ya decidiste de lo que necesitas comprobar.
1. ¿Quién necesita hacer qué y en qué momento?
Decir que una app es «para clientes» identifica un público, pero no una tarea. ¿La persona necesita comparar opciones, solicitar un servicio, consultar el estado de un trámite o corregir información? ¿En qué situación lo hará y qué utiliza hoy para conseguirlo? Elegir una tarea prioritaria permite diseñar una experiencia concreta, en vez de intentar acomodar todas las funciones imaginables en la primera versión.
También importa quién participa después de que el cliente envía una solicitud. En una plataforma de reservas, por ejemplo, quien elige una fecha no siempre es quien confirma la disponibilidad o resuelve un cambio. Conocer esos papeles evita que la interfaz prometa una respuesta inmediata cuando la operación aún requiere una revisión humana. La guía de investigación de usuarios de GOV.UK recomienda comprender qué intentan lograr las personas, cómo lo hacen hoy y qué dificultades encuentran antes de definir una solución.
2. ¿Dónde comienza y dónde termina la tarea?
Una lista de pantallas no muestra cómo se completa una acción. Para describirla, usa verbos sencillos: la persona entra, elige, proporciona datos, revisa, confirma y recibe una respuesta. Después identifica qué necesita saber en cada paso y cómo reconocerá que avanzó. Esa secuencia da una base al diseño y permite detectar pasos innecesarios o información que llega demasiado tarde.
Imaginemos una empresa que quiere digitalizar sus solicitudes de servicio. Si la propuesta termina en «solicitud enviada», pero nadie ha definido cuándo se asigna un responsable ni cómo se comunica la aceptación, la pantalla muestra una conclusión que la operación todavía no puede sostener. La guía de diseño de servicios de GOV.UK propone observar el servicio de principio a fin, incluida la actividad interna que hace posible lo que ve quien lo utiliza.
“Una pantalla termina donde el producto debe responder; si nadie sabe qué ocurre después, la tarea sigue incompleta.”
Puedes escuchar este artículo aquí:
3. ¿Qué información, reglas y responsables sostienen cada paso?
Cada acción visible depende de decisiones que quizá no aparezcan en la pantalla final. Si una persona puede reservar, ¿de dónde sale la disponibilidad? Si puede cancelar, ¿hasta cuándo? Si consulta el estado de una solicitud, ¿quién lo actualiza? Responder estas preguntas ayuda a distinguir lo que el cliente necesita ver de lo que el equipo debe resolver para cumplir la promesa del servicio.
No hace falta escribir un manual exhaustivo antes de comenzar. Sí conviene acordar las reglas que cambian el resultado e identificar las que siguen abiertas. «Mostrar horarios disponibles» parece una función sencilla hasta que dos personas eligen el último espacio al mismo tiempo. Si nadie decide cómo se atenderá esa situación, el diseño puede representar una confirmación que el producto no podrá cumplir. Cuando el trabajo actual depende de mensajes y hojas de cálculo, también puede ser útil revisar cómo convertir una operación manual en un flujo digital antes de trasladarla a una interfaz.
4. ¿Qué debe pasar cuando algo sale mal?
Muchas propuestas muestran únicamente a una persona que introduce datos correctos, recibe una respuesta y termina. Un producto también debe atender errores, esperas, cambios y tareas interrumpidas. ¿Qué ocurre si falta un dato, se rechaza un pago o la solicitud no puede procesarse? ¿Puede la persona corregir el problema sin empezar de nuevo? Estas situaciones afectan tanto el contenido de las pantallas como la confianza en el servicio.
Elige las excepciones más probables o más delicadas y describe qué verá la persona y quién deberá actuar. No basta con indicar «mostrar error»: el mensaje tiene que explicar qué sucedió y, cuando sea posible, cómo continuar. Para contenido web, el criterio 3.3.1 de WCAG 2.2, explicado por el W3C, establece que un error de entrada detectado automáticamente debe identificar el elemento afectado y describir el problema en texto. Considerar esos estados antes de aprobar las pantallas ayuda a que la experiencia siga siendo comprensible cuando el camino previsto se interrumpe.
“El diseño más útil no solo muestra cómo empezar: permite saber qué hacer cuando aparece una dificultad.”
Puedes ver este artículo aquí:
5. ¿Qué necesitas comprobar antes de desarrollar?
Un diseño temprano puede convertir una idea en algo que las personas recorran y cuestionen. Por eso, define primero qué duda quieres resolver. Quizá no sabes si el cliente comprende las opciones, si el personal puede atender las solicitudes con ese proceso o si alguien reconoce cuándo su trámite quedó confirmado. Una pregunta concreta ayuda a decidir qué representar primero y con quién revisarlo.
Si quieres comprobar una reserva, no necesitas diseñar de inmediato todas las secciones de la futura app. Necesitas mostrar el recorrido, su resultado y las dificultades importantes para observar si las personas pueden completarlo y explicar qué creen que ocurrió. La guía de prototipos de GOV.UK recomienda probar distintas propuestas antes de comprometerse con su construcción. Lo que descubras puede confirmar el rumbo, pedir un ajuste o revelar una decisión operativa que sigue pendiente.
Responder estas cinco preguntas permite llegar al diseño con una tarea prioritaria, un recorrido entendible, reglas visibles y dudas que vale la pena probar. Así, las pantallas ayudan a tomar decisiones y el equipo reconoce qué falta resolver antes de invertir en desarrollo. ¿Tu idea necesita más claridad antes de convertirse en código? ¿Cuál de estas cinco preguntas te cuesta más responder? En Señor Zorro Estudio de diseño de productos digitales, te ayudamos a definir, validar y diseñar productos digitales listos para desarrollo. Conoce más en www.srzorro.com.
Escrito por: Editorial
Comentarios