Diseño centrado en el usuario… ¿sin usuarios representativos?
Escrito por Marc Sanmartí el 21 May 2007
Desarrollar un proyecto con una metodología centrada en el usuario va más allá de diseñar pensando en el usuario. Generalmente implica utilizar técnicas que requieren la participación de usuarios, que además deberían ser usuarios reales o representativos del producto que se quiere crear.
Sin embargo, a veces, no se dispone del tiempo o el dinero suficiente para emplear todas las técnicas que a uno le gustarían y de reclutar a “suficientes” usuarios representativos. Con lo que es necesario acotar: realizar menos pruebas, emplear menos usuarios, usar usuarios menos representativos, etc.
Reducir el alcance de un proyecto disminuyendo el número de pruebas a realizar o el número de usuarios es fácil de comprender, pero ¿cuándo se puede acotar reclutando usuarios menos representativos?
Libros como el famoso No me hagas pensar de Steve Krug, defienden la idea que todo proyecto se debe probar y cuantas más veces mejor. Comentan que generalmente es mejor realizar muchas pruebas y frecuentemente durante todo el desarrollo, incluso si se recurre a familiares o conocidos, que una única prueba al final del proyecto con usuarios representativos.
Coincido en que cuando se están analizando aspectos generales de usabilidad (tamaño del texto, contraste de colores, situación de los menús, etc.), la mayoría de veces cualquier usuario, sea representativo o no, aporta información valiosa que ayuda a mejorar el producto final. Sin embargo, no se debe aplicar este razonamiento a todas las técnicas del diseño centrado en el usuario.
Cuando se está trabajando junto a usuarios en la creación de una arquitectura de la información con técnicas como el Card Sorting, reclutar usuarios no representativos puede hacer que los resultados obtenidos no sean fiables.
Por ejemplo, si el proyecto consiste en el rediseño de una intranet y se está trabajando en su arquitectura de la información, los usuarios deberían ser los empleados y otras personas que habitualmente trabajen con la herramienta. Si en vez de ello utilizamos conocidos u otro tipo de usuario, puede suceder que se creen categorías poco claras, etiquetas ambiguas o que no se ajuste a la forma de trabajar de los usuarios habituales de la intranet.
Comentarios (1)
Participa en la conversación, escribe tu comentario:
Notas sobre el comentario
- Usa un tono respetuoso.
- Las lineas saltan automáticamente sin pulsar la tecla "Enter".
- Para escribir en negrita: <strong>texto en negrita</strong>
- Para escribir en itálica: <em>texto en itálica</em>
- Para crear un enlace: <a href="URL">texto del enlace</a>
El blog de Usolab está bajo una
licencia de Creative Commons.
Ferran dijo el 31 May 2007:
Creo que tu razonamiento es evidente. Los usuarios representativos o usuarios expertos son siempre estrictamente necesarios. Pero a veces, te pueden hacer caer en un desarrollo tan personalizado a nivel individual, que puede covertirse en incómodo a nivel de grupo o de conjunto. También el usuario representativo puede cegarse en la aplicación que él desea y no en la que mas le combiene o más le puede ayudar, debido esas malas costumbres intrinsicas asumidas dentro de su flujos de negocio. Creo que ahí esta nuestra labor de abstracción y poder equilibrar la usuabilidad a nivel general con la comodidad a nivel individual.