El diseño centrado en el usuario ( UCD ) o desarrollo dirigido por el usuario ( UDD ) es un marco de proceso (no restringido a interfaces o tecnologías) en el que se dan objetivos de usabilidad , características del usuario, entorno , tareas y flujo de trabajo de un producto , servicio o proceso. Amplia atención en cada etapa del proceso de diseño . Estas pruebas se llevan a cabo con o sin usuarios reales durante cada etapa del proceso, desde los requisitos , los modelos de preproducción y la posproducción, completando un círculo de prueba y asegurando que "el desarrollo avanza con el usuario como centro de atención". [1] [2] Estas pruebas [3] son necesarias ya que a menudo es muy difícil para los diseñadores de un producto comprender intuitivamente a los usuarios primerizos de sus experiencias de diseño y cómo puede ser la curva de aprendizaje de cada usuario. El diseño centrado en el usuario se basa en la comprensión de un usuario, sus demandas, prioridades y experiencias y, cuando se utiliza, se sabe que conduce a una mayor utilidad y usabilidad del producto, ya que brinda satisfacción al usuario. [4]
La principal diferencia con otras filosofías de diseño de productos es que el diseño centrado en el usuario intenta optimizar el producto en torno a cómo los usuarios pueden, quieren o necesitan usarlo para que no se vean obligados a cambiar su comportamiento y expectativas para adaptarse al producto. Los usuarios se sitúan así en el centro de dos círculos concéntricos. El círculo interior incluye el contexto del producto, los objetivos de su desarrollo y el entorno en el que se ejecutaría. El círculo exterior implica detalles más granulares de los detalles de la tarea, su organización y su flujo. [2]
El término "Diseño centrado en el usuario" fue acuñado por Rob Kling en 1977 [5] y posteriormente adoptado en el laboratorio de investigación de Donald A. Norman en la Universidad de California, San Diego . El concepto se hizo muy popular como resultado de la publicación del libro Diseño de sistemas centrados en el usuario: nuevas perspectivas sobre la interacción persona-computadora en 1986. [6] El concepto ganó mayor atención y aceptación en el libro fundamental de Norman, El diseño de las cosas cotidianas ( originalmente llamado La Psicología de las Cosas Cotidianas ). En este libro, Norman describe la psicología detrás de lo que él considera diseño "bueno" y "malo" a través de ejemplos. Exalta la importancia del diseño en nuestra vida cotidiana y las consecuencias de los errores provocados por malos diseños.
Los dos libros incluyen principios para crear productos bien diseñados. Sus recomendaciones se basan en las necesidades del usuario, dejando de lado lo que considera cuestiones secundarias como la estética. Los principales aspectos destacados de estos son:
En un libro posterior, Emotional Design , [7] : p.5 en adelante, Norman vuelve a algunas de sus ideas anteriores para elaborar lo que había llegado a considerar demasiado reduccionista.
Por ejemplo, el proceso de diseño centrado en el usuario puede ayudar a los diseñadores de software a cumplir el objetivo de un producto diseñado para sus usuarios. Los requisitos del usuario se consideran desde el principio y se incluyen en todo el ciclo del producto. Estos requisitos se anotan y perfeccionan mediante métodos de investigación que incluyen: estudio etnográfico, investigación contextual , pruebas de prototipos, pruebas de usabilidad y otros métodos. También se pueden utilizar métodos generativos que incluyen: clasificación de tarjetas , diagramas de afinidad y sesiones de diseño participativo. Además, los requisitos del usuario pueden inferirse mediante un análisis cuidadoso de productos utilizables similares al producto que se está diseñando.
El diseño centrado en el usuario se inspira en los siguientes modelos:
Estos son los principios que ayudan a garantizar que un diseño esté centrado en el usuario: [11]
El objetivo del diseño centrado en el usuario es fabricar productos que tengan una usabilidad muy alta . Esto incluye qué tan conveniente es el uso del producto, su capacidad de administración, su efectividad y qué tan bien se adapta el producto a los requisitos del usuario. A continuación se detallan las fases generales del proceso de Diseño Centrado en el Usuario: [13] [14]
El procedimiento anterior se repite en los siguientes pasos para terminar aún más el producto. Estas fases son enfoques generales y factores como los objetivos de diseño, el equipo y su cronograma, y el entorno en el que se desarrolla el producto, determinan las fases apropiadas para un proyecto y su orden. Puede seguir un modelo en cascada , un modelo ágil o cualquier otra práctica de ingeniería de software .
UCD hace preguntas sobre los usuarios y sus tareas y objetivos, luego utiliza los hallazgos para tomar decisiones sobre el desarrollo y el diseño. El UCD de un sitio web, por ejemplo, busca responder a las siguientes preguntas:
Como ejemplo de puntos de vista UCD, los elementos esenciales de UCD de un sitio web suelen ser las consideraciones de visibilidad, accesibilidad, legibilidad y lenguaje.
La visibilidad ayuda al usuario a construir un modelo mental del documento. Los modelos ayudan al usuario a predecir los efectos de sus acciones mientras utiliza el documento. Los elementos importantes (como los que ayudan a la navegación ) deben ser enfáticos. Los usuarios deberían poder saber de un vistazo qué pueden y qué no pueden hacer con el documento.
Los usuarios deberían poder encontrar información rápida y fácilmente en todo el documento, independientemente de su extensión. A los usuarios se les deben ofrecer varias formas de encontrar información (como elementos de navegación, funciones de búsqueda, tabla de contenidos, [15] secciones claramente etiquetadas, números de página, códigos de colores , etc.). Los elementos de navegación deben ser coherentes con el género del documento. La ' fragmentación ' es una estrategia útil que implica dividir la información en pequeños fragmentos que pueden organizarse en algún orden o jerarquía significativo . La capacidad de hojear el documento permite a los usuarios encontrar información escaneando en lugar de leyendo. Con este fin se suelen utilizar palabras en negrita y cursiva .
El texto debe ser fácil de leer: mediante el análisis de la situación retórica, el diseñador debe poder determinar una familia de fuentes y un estilo de fuente útiles . Las fuentes ornamentales, el texto en mayúsculas y el cuerpo del texto grande o pequeño pueden ser difíciles de leer y deben evitarse. El color del texto y la negrita pueden resultar útiles cuando se utilizan en escenarios con mucho texto. El alto contraste entre la figura y el fondo entre el texto y el fondo aumenta la legibilidad. El texto oscuro sobre un fondo claro es más legible.
Se necesitan ciertos tipos de lenguajes dependiendo de la situación retórica. Las oraciones cortas son útiles, al igual que los textos bien escritos utilizados en explicaciones y situaciones similares de texto masivo. A menos que la situación lo requiera, no se deben utilizar jergas ni términos muy técnicos. Muchos escritores optarán por utilizar la voz activa , verbos (en lugar de cadenas de sustantivos o nominales ) y una estructura de oración simple.
Existen una serie de herramientas que se utilizan en el análisis del Diseño Centrado en el Usuario, principalmente: personas, escenarios y casos de uso esenciales.
Durante el proceso de UCD, se puede crear una Persona que represente al usuario. Una persona es un arquetipo de usuario que se utiliza para ayudar a guiar las decisiones sobre las características del producto, la navegación, las interacciones e incluso el diseño visual. En la mayoría de los casos, las personas se sintetizan a partir de una serie de entrevistas etnográficas con personas reales, luego se capturan en descripciones de 1 a 2 páginas que incluyen patrones de comportamiento, objetivos, habilidades, actitudes y entorno, con algunos detalles personales ficticios para acercar a la persona. vida. [dieciséis]
Para cada producto, o a veces para cada conjunto de herramientas dentro de un producto, hay un pequeño conjunto de personas, una de las cuales es el foco principal del diseño. También existe lo que se llama una persona secundaria, donde el personaje no es el objetivo principal del diseño, sino que se deben satisfacer sus necesidades y resolver los problemas si es posible. Existen para ayudar a dar cuenta de posibles problemas y dificultades adicionales que puedan ocurrir incluso si la persona principal está satisfecha con su solución. También existe una antipersona, que es el personaje para el cual el diseño no está hecho específicamente.
Las personas son útiles porque crean una comprensión común compartida del grupo de usuarios en torno al cual se construye el proceso de diseño. Además, ayudan a priorizar las consideraciones de diseño al proporcionar un contexto de lo que el usuario necesita y qué funciones es bueno agregar y tener. También pueden proporcionar un rostro y una existencia humanos a un grupo de usuarios diversificado y disperso y ayudar a crear empatía y agregar emociones al referirse a los usuarios. Sin embargo, dado que las personas son una percepción generalizada del grupo de partes interesadas principal a partir de los datos recopilados, las características pueden ser demasiado amplias y típicas o demasiado parecidas a las de un "persona promedio". A veces, las personas pueden tener propiedades estereotipadas, lo que puede perjudicar todo el proceso de diseño. En general, las personas pueden ser una herramienta útil que los diseñadores pueden utilizar para tomar decisiones de diseño informadas, en lugar de referirse a un conjunto de datos o una amplia gama de individuos.
Las personas también se pueden modificar a través del UCD de un producto, según las pruebas de los usuarios y el entorno cambiante. Esta no es una forma ideal de usar Personas , pero tampoco debería ser un tabú, particularmente cuando se hace evidente que las variables que rodean el desarrollo de un producto han cambiado desde que comenzó el diseño y las personas actuales pueden no adaptarse bien a las condiciones cambiantes.
Un escenario creado en el proceso de UCD es una historia ficticia sobre la "vida diaria de" o una secuencia de eventos con el grupo de partes interesadas principales como personaje principal. Normalmente, una persona creada anteriormente se utiliza como personaje principal de esta historia. La historia debe ser específica de los eventos que se relacionan con los problemas del grupo de partes interesadas principales y, normalmente, las principales preguntas de investigación sobre las que se construye el proceso de diseño. Estas pueden resultar ser una historia simple sobre la vida diaria de un individuo. Aún así, los pequeños detalles de los eventos deberían implicar detalles sobre los usuarios y pueden incluir características emocionales o físicas. Puede haber el mejor de los casos , donde todo sale mejor para el personaje principal, el peor de los casos , donde el personaje principal experimenta que todo va mal a su alrededor, y un escenario promedio , que es la vida típica. del individuo, donde no ocurre nada realmente especial o deprimente, y el día continúa.
Los escenarios crean un contexto social en el que las personas existen y crean un mundo físico real, en lugar de imaginar un personaje con características internas a partir de datos recopilados y nada más, hay más acción involucrada en la existencia de la persona. Las personas también entienden más fácilmente un escenario, ya que es una historia y es más fácil de seguir. Sin embargo, al igual que las personas, estos escenarios son suposiciones hechas por el investigador y el diseñador y también se crean a partir de un conjunto de datos organizados. Es importante garantizar que los escenarios se creen lo más parecidos posible a los escenarios del mundo real. Sin embargo, a veces puede resultar difícil explicar e informar cómo se producen las tareas de bajo nivel, por ejemplo, el proceso de pensamiento de una persona antes de actuar.
En resumen, un caso de uso describe la interacción entre un individuo y el resto del mundo. Cada caso de uso describe un evento que puede ocurrir durante un corto período de tiempo en la vida real pero que puede consistir en detalles e interacciones intrincados entre el actor y el mundo. Se representa como una serie de pasos sencillos para que el personaje logre su objetivo a través de un esquema de causa y efecto. Los casos de uso normalmente se escriben en forma de gráfico con dos columnas: la primera columna denominada actor , la segunda columna denominada mundo y las acciones realizadas por cada lado escritas en orden en las columnas respectivas. El siguiente es un ejemplo de un caso de uso para interpretar una canción con una guitarra frente a una audiencia.
La interacción entre el actor y el mundo es un acto que se puede ver en la vida cotidiana, y lo damos por sentado y no pensamos demasiado en los pequeños detalles que deben suceder para que exista un acto como interpretar una pieza musical. . Es similar al hecho de que cuando hablamos nuestra lengua materna, no pensamos demasiado en la gramática y en cómo expresar las palabras; simplemente salen porque estamos tan acostumbrados a decirlas. Las acciones entre un actor y el mundo, en particular, el principal interesado (usuario) y el mundo en este caso, deben considerarse en detalle. Por lo tanto, se crean casos de uso para comprender cómo ocurren estas pequeñas interacciones.
Un caso de uso esencial es un caso de uso especial, también llamado caso de uso abstracto . Los casos de uso esenciales describen la esencia del problema y abordan la naturaleza del problema en sí. Al escribir casos de uso esenciales, no se deben hacer suposiciones sobre detalles no relacionados. Además, los objetivos de la asignatura deben separarse del proceso y la implementación para alcanzar ese objetivo en particular. A continuación se muestra un ejemplo de un caso de uso esencial con el mismo objetivo que el anterior.
Los casos de uso son útiles porque ayudan a identificar niveles útiles de trabajo de diseño. Permiten a los diseñadores ver los procesos reales de bajo nivel que están involucrados en un determinado problema, lo que hace que el problema sea más fácil de manejar, ya que se exponen ciertos pasos y detalles menores que realiza el usuario. El trabajo de los diseñadores debería ser tener en cuenta estos pequeños problemas para llegar a una solución final que funcione. Otra forma de decir esto es que los casos de uso dividen tareas complicadas en bits más pequeños, donde estos bits son unidades útiles. Cada bit completa una pequeña tarea, que luego se convierte en la tarea final más grande. Al igual que escribir código en una computadora, es más fácil escribir las partes básicas más pequeñas y hacer que funcionen primero, y luego juntarlas para terminar el código más grande y complicado, en lugar de abordar el código completo desde el principio.
La primera solución es menos riesgosa porque si algo sale mal con el código, es más fácil buscar el problema en los bits más pequeños, ya que el segmento con el problema será el que no funcione, mientras que en la segunda solución, el Es posible que el programador tenga que revisar todo el código para buscar un solo error, lo que lleva mucho tiempo. El mismo razonamiento se aplica a la escritura de casos de uso en UCD. Por último, los casos de uso transmiten tareas útiles e importantes donde el diseñador ahora puede ver cuáles son de mayor importancia que otras. Algunas desventajas de escribir casos de uso incluyen el hecho de que cada acción, del actor o del mundo, consta de pocos detalles y es simplemente una acción pequeña. Es posible que esto conduzca a una mayor imaginación y a una interpretación diferente de la acción por parte de diferentes diseñadores.
Además, durante el proceso, es muy fácil simplificar demasiado una tarea, ya que una tarea pequeña derivada de una tarea más grande aún puede consistir en tareas aún más pequeñas que se omitieron. Coger una guitarra puede implicar pensar qué guitarra coger, qué púa usar y pensar primero en dónde se encuentra la guitarra. Estas tareas luego se pueden dividir en tareas más pequeñas, como pensar primero qué color de guitarra se adapta al lugar para interpretar la pieza y otros detalles relacionados. Las tareas se pueden dividir en tareas aún más pequeñas, y corresponde al diseñador determinar cuál es el lugar adecuado para dejar de dividir las tareas. Es posible que las tareas no sólo se simplifiquen demasiado, sino que también se omitan por completo, por lo que el diseñador debe ser consciente de todos los detalles y todos los pasos clave que intervienen en un evento o acción al escribir casos de uso.