Investigación con usuarios
Entrevistas por videollamada con personas del público real y análisis de la analítica y de las consultas de soporte.
Muchas empresas llegan al diseño cuando ya tienen un problema medible: usuarios que no terminan una reserva, empleados que tardan diez minutos en una tarea de dos, clientes que llaman para hacer algo que la web ya permite. En ese punto, cambiar colores no sirve; hay que entender dónde se atasca la gente y por qué. Pongamos una red de clínicas de fisioterapia de Sevilla que quiere cita online: los pacientes mayores no encuentran el botón de confirmar y los jóvenes abandonan cuando se les pide registrarse. Esos dos hallazgos, que salen de ver a seis personas usar un prototipo, valen más que cualquier opinión interna.
Cada ciclo de diseño produce entregables concretos que su equipo puede usar sin Apply. Estos son los habituales.
Entrevistas por videollamada con personas del público real y análisis de la analítica y de las consultas de soporte.
Descripción paso a paso de las tareas principales: objetivo del usuario, pasos, información necesaria y puntos de abandono actuales.
Maquetas en gris convertidas en un prototipo clicable en Figma, suficiente para probar el recorrido antes de programar.
Sesiones con cinco a ocho participantes por perfil, grabadas con su permiso, y un informe de problemas ordenados por gravedad.
Diseño visual final con colores, tipografía, estados, mensajes de error y versiones móviles, organizado como biblioteca de componentes.
Contrastes, tamaños táctiles, orden de foco y etiquetas decididos según WCAG 2.1 AA y, en proyectos públicos, la UNE-EN 301549.
Especificaciones, recursos exportados y revisión de lo implementado para que el producto final coincida con lo probado.
Un ciclo completo, de las entrevistas al prototipo probado, suele durar pocas semanas. Los proyectos grandes se dividen en varios ciclos, uno por recorrido.
Entrevistas por videollamada con usuarios reales y revisión de la analítica y de las consultas de soporte para localizar dónde se atasca la gente.
Maquetas en gris del recorrido principal convertidas en un prototipo navegable en Figma, sin dedicar todavía tiempo al aspecto visual.
De cinco a ocho personas intentan completar tareas concretas con el prototipo mientras observamos. Los problemas se corrigen entre una sesión y la siguiente.
Interfaz definitiva, biblioteca de componentes documentada y sesión con los desarrolladores para resolver dudas antes de programar.
Los usuarios dicen una cosa y hacen otra. En una encuesta, casi todos afirman que prefieren registrarse para guardar sus datos; en la práctica, muchos abandonan cuando aparece el formulario de registro. Por eso las decisiones importantes se toman observando a personas que usan un prototipo, no preguntándoles qué preferirían. Una entrevista explica el porqué; una sesión de prueba enseña el qué.
Depende del número de recorridos y de sesiones de prueba. Un recorrido concreto, como una reserva o un alta, es un trabajo de pocas semanas; una aplicación completa se divide en ciclos. Presupuestamos por ciclo a 75 €/h + IVA, para que pueda parar después de cualquiera de ellos.
No. Las sesiones se hacen por videollamada: el participante comparte pantalla desde su ordenador o su móvil y usa el prototipo en su propio entorno. Es más cómodo para él y más realista para el resultado.
Para detectar los problemas principales de un recorrido bastan de cinco a ocho personas del público real. Si hay perfiles muy distintos, por ejemplo pacientes y personal de recepción, conviene un grupo pequeño de cada perfil.
Sí, es lo habitual. Entregamos una biblioteca de componentes en Figma con especificaciones y hacemos sesiones con sus desarrolladores durante la implementación, para que el resultado se parezca a lo que se probó.
Sí. Contrastes, tamaño de las zonas táctiles, orden de navegación con teclado y etiquetas de formulario se deciden en el diseño según WCAG 2.1 AA. En proyectos públicos aplicamos además la UNE-EN 301549, a la que remite el Real Decreto 1112/2018.
Describa el producto o la web que quiere diseñar y quién lo va a usar. Le proponemos un método y un número de ciclos.
Hemos recibido su solicitud
Tendrá respuesta en un día laborable. Si nos avisa de una avería que tiene parado a su equipo, la tratamos con prioridad.
No encontramos esa ciudad. Revise cómo está escrita o elija la capital de provincia más cercana: como trabajamos en remoto, el servicio es el mismo en cualquier punto de España.