¿Alguna recomendación sobre cómo combinar Shape Up y las pruebas de usabilidad? ¿Cuándo es el buen momento para ello? ¿Debe incluirse en el ciclo? ¿Quién debe asumir la responsabilidad por ello?
- Perceptivo: “No sabían qué hacer a continuación”, “no podían encontrar la función”, “no sabían que podían hacer clic en ese botón…”, etc.
- Específico del dominio: “Necesitamos una forma de regresar aquí porque en su flujo de trabajo sucede esto…”
Considero que la usabilidad perceptiva tipo 1 pertenece a la educación y capacitación de un diseñador al principio de su carrera, no como parte de proyectos de producción. Una vez que conozca los conceptos básicos, puede aplicarlos una y otra vez a cualquier proyecto. Por eso nunca he hecho ese tipo de pruebas de usabilidad en proyectos.
Los problemas específicos de dominio de tipo 2 son muy diferentes. Los de entender lo que importa para hacer el diseño trabajar para que haga el trabajo para el propósito específico en la situación específica. Para hacer eso, debe comprender el mundo que rodea al diseño y el progreso que las personas intentan lograr cuando lo usan.
Si intenta hacer eso con las pruebas, ya es demasiado tarde. Debe comprender el problema que está resolviendo en las primeras etapas, antes de crear algo para probar. Se trata de formar una mejor hipótesis.
En términos de proceso, puse la usabilidad específica de dominio tipo 2 en la fase de configuración. Acertar primero significa hacer la investigación y/o vivir el problema para que entiendas qué hacer. Probar en esta etapa significa conectar prototipos tempranos y baratos a la vida real para ver qué sucede.
Por ejemplo, la primera versión de Hill Chart en Basecamp fue una hoja de cálculo de Numbers que construí que generaba los gráficos. Usamos la hoja de cálculo en proyectos reales para estar seguros de que era realmente útil antes de construirla con el software.
Para detectar y resolver problemas de usabilidad específicos del dominio, lo más importante es comprender primero el problema y el resultado deseado, independientemente de la solución de diseño particular. Si comprende profundamente el espacio en el que debe encajar la solución, puede iterar sin probadores de terceros.
Este enfoque es la forma más rentable de detectar la mayoría de los problemas de usabilidad. El diseñador debe internalizar la usabilidad perceptual como parte de su conjunto de habilidades; no debería necesitar aprender las mismas lecciones una y otra vez. Los grandes problemas específicos del dominio deben detectarse y prevenirse temprano con la investigación y probando prototipos baratos en las fases de configuración y configuración previa, antes de apostar y construir todo.
Detectar el último 5-10% de los problemas antes del lanzamiento es algo entre prohibitivamente costoso e imposible. Es mucho mejor enviar, llevar el producto a la vida real y luego priorizar qué hacer en proyectos futuros en función de los comentarios. Una cadencia regular (por ejemplo, ciclos de seis semanas) y un camino claro desde el problema hasta la mejora moldeada y la ejecución lo permiten.
