Imagina una aplicación interna donde registrar un pedido toma once clics porque cada área pidió su propio campo y nadie quiso quitar el anterior. Crecieron pantalla por pantalla, y cada decisión parecía razonable por separado.
Entender antes de dibujar
El diseño empieza con preguntas que no tienen nada de gráfico: quién usa esto, en qué momento del día, desde qué dispositivo, qué intenta lograr y qué le estorba hoy. Unas pocas conversaciones cortas con usuarios reales suelen aclarar más que una semana de suposiciones en una sala de reuniones. A veces revelan un paso del proceso que sobra.
Con el ejemplo de los once clics, eso significa mirar a tres o cuatro personas registrar pedidos de verdad y anotar qué campos llenan cada vez y cuáles dejan en blanco. Los que casi nadie usa se quitan o pasan a una sección opcional. Los que usa solo un área se muestran solo a esa área. La decisión se apoya en lo observado y no en quién insistió más.
De ahí salen los flujos: el recorrido que hace una persona para cumplir una tarea, con sus caminos alternos y sus errores posibles. Dibujarlos en papel o en Figma es barato. Cambiarlos cuando ya están en código cuesta más, porque hay que tocar pantallas, pruebas y datos.
Prototipos baratos, decisiones rápidas
Basta un prototipo navegable, sin una línea de código. Se muestra a alguien y se mira dónde duda. Si tres de cinco personas buscan el botón de guardar en el lugar equivocado, ya sabes qué mover. Un prototipo así toma poco tiempo y pertenece a una fase corta de descubrimiento, como explicamos al hablar de estimaciones.
Un sistema visual evita decisiones repetidas
Cuando colores, tipografías, espacios y componentes salen de un sistema compartido, el equipo deja de discutir si el botón lleva esquinas redondeadas y se concentra en el problema del usuario. El producto se ve coherente aunque lo construyan varias personas, y para el desarrollo un sistema de diseño significa componentes reutilizables y menos código duplicado.
Accesibilidad desde el principio
Contraste suficiente entre texto y fondo, zonas táctiles de al menos 24 píxeles CSS (criterio 2.5.8 de WCAG 2.2 nivel AA, aunque en el móvil se tocan con comodidad las de 44), orden lógico para quien navega con teclado y etiquetas claras en cada campo. Son decisiones de diseño. Tomarlas al inicio evita rehacer pantallas terminadas.
Las palabras también son diseño
Un mensaje de error que dice una cosa en el formulario y otra en el correo de confirmación obliga a reescribir textos en tres pantallas cuando alguien lo nota. Decidir el tono, los nombres de las secciones y la redacción de los errores junto con el flujo evita ese retrabajo.
Seis preguntas para la primera sesión
Llévalas a la reunión de descubrimiento y no cierres el diseño hasta tener respuesta para cada una:
- ¿Quién usará esto a diario y quién solo de vez en cuando?
- ¿Qué tarea es la más frecuente y cuántos pasos toma hoy?
- ¿Desde qué dispositivo y en qué condiciones se usa, con prisa, con mala conexión, de pie?
- ¿Qué parte del proceso actual existe solo por costumbre?
- ¿Qué error cuesta más y cómo debería avisar la interfaz?
- ¿Quién decide cuando dos áreas piden cosas opuestas?
Elige la pantalla más torpe de tu producto y envíanosla. La recorremos contigo antes de tocar código, dentro de nuestro servicio de aplicaciones web a medida.