Ver el código de «Diseño Centrado en los Usuarios (2010)»

{{Curso
|Asignaturas Relacionadas=Lenguaje Computacional 2,
|Tipo de Curso=Ramo Lectivo
|Profesores=Jorge Barahona,
|Ayudantes=Dámaris Sepúlveda,
|Carreras Relacionadas=Diseño Gráfico
|Nombre=LC2 Lenguaje Computacional 2
}}
= Estrategia, Estudio del Comportamiento de los Usuarios y Arquitectura de la Información =

== Presentación== 
El siguiente Ramo pertenece al grupo de ramos transversales a la carrera de Diseño Gráfico llamados Lenguaje Computacional y que trabajan en torno a la '''Metodología del Diseño para Personas''' que se ocupa del '''Diseño de Experiencias para medios digitales''' y que está compuesta por:
* Estrategia
* Estudio del Comportamiento de las Personas
* Arquitectura de la Información
* Diseño de Interacción
* Diseño de Interfaz
* Diseño de Códigos de Interfaz

== Estrategia ==

La [http://es.wikipedia.org/wiki/Estrategia estrategia] es "un conjunto de acciones que se llevan a cabo para lograr un determinado fin. 
Proviene del griego ΣΤΡΑΤΗΓΙΚΗΣ, ''Stratos'' = Ejército y ''Agein'' = conductor, guía.   

El diseñador es siempre un estratega, un guía que, a través de las acciones que acomete busca lograr una obra final, un puente de comunicación entre otros.

'''Qué + Cuándo + Quiénes + Cómo'''

Como en cualquier acción donde se logra conseguir un objetivo determinado, cualquier Estrategia de Diseño debe responder a cuáles son los objetivos del proyecto, qué se desea lograr, qué tácticas utilizaremos, los tiempos, recursos y cuáles serán los mecanismos de medición de lo realizado.

El acto de Diseño es en sí mismo uno que busca construir '''Experiencias''' y para ello es fundamental diseñar estrategias.

Los diseñadores trabajamos habitualmente haciendo obras que construirán '''comunicación entre otros'''. Por lo mismo es básico entender lo que los hablantes desean comunicarse, o lo que desea el emisor del mensaje comunicar. 

Para ello el [http://es.wikipedia.org/wiki/Briefing brief]  es una herramienta fundamental, porque permite que el emisor del mensaje declare sus intenciones, piense en las estrategias, acote los objetivos, construya los límites y consecuencias que espera de la obra a diseñar.

A la vez el acto de briefing permite que el diseñador entienda los alcances reales del proyecto, su presupuesto y lo más importante cuáles serán los mecanismos de medición que tendrá su trabajo.

Una estrategia para el '''Diseño de Experiencia Digital'''' tiene al menos tres componentes fundamentales:

===Brief===
Es un resumen que contiene respuestas a preguntas sencillas pero trascendentales para ejecutar el proyecto.
Está dividido en: 
: Información General del Proyecto (nombres, cargos y datos de los responsables directos)
: Tipo de proyecto (web, móvil, juegos, etc.)
: Servicios de la competencia
: Audiencias (tipos de segmentación)
: Contenidos
: Imagen
: Información técnica

'''Contra Brief'''

Es el acto de preguntar lo que queda poco claro desde la lectura y análisis del brief. Este proceso es especialmente importante ya que permite abrir la conversación y ajusta la comprensión del problema a resolver

'''De Brief'''

Es el acto posterior a la liberación del trabajo encomendado para determinar si se cumplieron los objetivos planteados en el brief.

Información adicional:
* [http://wiki.ead.pucv.cl/images/0/05/Brief.pdf Plantilla Brief]
* [http://www.jbarahona.com/2009/08/03/la-importancia-del-brief-en-el-proceso-de-diseno/ La importancia del Brief en el proceso de Diseño]
* [http://es.wikipedia.org/wiki/Debriefing Debriefing]

===Conversaciones guiadas===
Es un encuentro informal y distendido con un al menos 5 usuarios finales donde se le hacen preguntas dirigidas y a conocer aspectos que enriquezcan nuestro conocimiento de sus motivaciones y qué problemáticas solucionará nuestra obra. 

Las conversaciones guiadas permiten escuchar a las audiencias, entender las motivaciones de los stakeholeders y desde ellas emergen nuevos insights que el Cliente, quien hace el encargo no ha percibido y no están en el brief.

===Benchmark ===
Es una técnica de medición que permite comparar la marca con la que estás trabajando con su competencia o aquellos que influyen el mercado. 
Sin embargo existen variables que permiten no sólo comparar si no también aprender de los errores y aciertos que tienen otros y que están directamente relacionado con los objetivos del proyecto o los targets a los que está dirigido.

Un benchmark consta de dos partes:
* '''Calificación de los servicios'''
Se apoya en una plantilla donde están las marcas o servicios y los criterios o preguntas que le haremos a cada uno de ellos. Un experto recorre los servicios digitales (sitios web, móviles, aplicaciones, juegos, etc.) y sobre la base de los criterios los califica numéricamente (por ejemplo del 1, muy malo al 7, muy bueno)

* '''Anotaciones del experto'''
Son aquellas menciones que hace el diseñador cuando navega o usa un sistema de la competencia y que permite destacar las buenas prácticas que éste competidor realiza como también los errores que comete.

Dichas anotaciones son mediciones de calidad que se sustentan en el conocimiento que tiene el evaluador de lo que son buenas o malas prácticas, normalmente asociadas a factores de de usabilidad, interacción, interfaces o de código de programación de interfaces.

==Estudio del Comportamiento de las Personas y Usabilidad==
El estudio de cuáles son los hábitos, motivaciones y el comportamiento de las personas al usar un sistema digital es fundamental para entender a quién le estamos diseñando, porque y para que.

Otra cosa es que esos sistemas funcionen al momentos de entregárselos y allí lo que medimos siempre es a dichos sistemas, no a los usuarios.

Ponemos a prueba lo que diseñamos y eso se debe hacer con un profundo respeto por las personas y sobre todo con el convencimiento que su feedback nos ayudará a enriquecer y mejorar la respuesta del sistema que estamos diseñando.

No olvidemos jamás que un diseño no es bueno porque es estéticamente agradable a los usuarios o lo que solemos llamar "hermoso", si no que es bueno porque combina estética y funcionalidad, esta última intimamente ligada con la capacidad de interacción que poseen los sistemas, de conversar con los usuarios para que ellos puedan finalmente usar de manera correcta y llevar a cabo las tareas y acciones que proponen las interfaces.

===Comportamiento de las personas===
Hay varias maneras de cómo las personas nos hablan acerca de sus motivaciones, necesidades y esperanzas de los servicios que les diseñamos. Porque lo que diseñamos en medios digitales son eso, servicios que quedan expuestos a su uso a través de las pantallas desde donde se pueden activar, dichos servicios a través de las interfaces.

Esto hace necesario comprender cómo consumen dichos servicios, qué los motiva a usarlos o no, qué están usando en su reemplazo o simplemente sobre la base de qué podemos solucionar problemáticas no resueltas.

====Personas y escenarios====
El enfoque de "personas" y "escenarios" es una técnica que facilita al diseñador ponerse en la situación de uso y bajo qué características etnográficas se usará el sistema que estamos diseñando.

La "persona" es una descripción detallada sobre la base de los conocimientos, comportamientos y habilidades de los distintos tipos de usuarios que tendrá un sistema digital. Cuando creamos una "persona" ésta es descrita e incluso le asignamos una fotografía de su rostro para identificarla en el proceso de diseño. Es una manera de identificar a quiénes estamos diseñando.

Por ejemplo "Lidia, es bailarina y madre de dos hijos pequeños a los que dedica gran parte de su tiempo cuando está en casa. Es de nivel socio-económico medio-medio (C3), con conocimientos medios de uso de computadoras las que usa normalmente para revisar sus correos electrónicos, postular a financiamientos públicos al arte, buscar noticias y blogs de danza"

Se diferencian las "personas" si sus objetivos de uso del sistema es distinto. Por ejemplo, Lidia va a su banco en línea sólo a ver sus saldos, jamás hace transacciones. Violeta, es otra "persona" de similar descripción etnográfica, pero sí hace operaciones de transferencia de dinero y pagos de servicios desde su casa a través del sitio web de su banco. Los objetivos son lo que diferencia a estas personas y cuando estamos diseñando, tenemos que diseñar para ambas.

Un "escenario" es la descripción de cómo la "persona" usará nuestro servicio, bajo qué condiciones físicas y ambientales. Construir dichos escenarios requiere de observaciones a las "personas" y sobre todo olvidar los escenarios propios de uso de los sistemas digitales.

====Modelos Mentales====

====Etnografía====

===Usabilidad===

====Expert Review====

====Test Heurístico====

====Evaluación de Eyetrack====




Enlaces de este capítulo: 
*[http://www.sidar.org/recur/desdi/traduc/es/visitable/inspeccion/Heur.htm  Evaluación Heurística]
*[http://www.nosolousabilidad.com/articulos/experiencia_del_usuario.htm  Experiencia de Usuario en NSU]
*[http://www.nosolousabilidad.com/articulos/heuristica.htm  Evaluación Heurística en NSU]
*[http://www.estandaresyaccesibilidad.com/2008/02/10-principios-para-un-diseo-web.html  10 Principios para un Diseño Web Efectivo en Estándares y Accesibilidad]
*[http://accesibilidadweb.blogspot.com/2008/01/lista-para-comprobar-si-un-sitio-web-es.html  39 sugerencias para hacer un sitio usable en Accesibilidad, Usabilidad y Estándares Web] 
*[http://www.laboratoriousabilidad.com/acceso.php  Autodiagnóstico de Usabilidad del Laboratorio Aragonés de Usabilidad ] 
*[http://www.laboratoriousabilidad.com/documentos/checklist.pdf  Checklist del Laboratorio Aragonés de Usabilidad]
*l[http://www.torresburriel.com/  Plantilla Análisis Heurístico v1.2 de Torres Burrie] 
*[http://www.nosolousabilidad.com/articulos/heuristica.htm  Guía de Evaluación Heurística de Sitios Web de NSU]
*[http://www.jmarquez.com/documentos/jm_checklist.pdf  Guía para evaluación experta de Joaquín Márquez Correa]
*[http://www.webusable.com/useTechniques_B.htm/weblog/2008/11/28/plantilla-para-hacer-analisis-heuristicos-de-usabilidad  Manual de las técnicas de Evaluación y testing de Usabilidad de WebUsable.com ]
*[http://cv.uoc.es/%7Edrodriguezgab/archive.htm  "Com es realitza una avaluació heurística per experts", PROYECTO MUPA-UOC - Metodología de usabilidad para aplicaciones de la Universitat Oberta de Catalunya]
*[http://www.itakora.com/  Taller de Usabilidad de la Semana de la Ciencia]
*[http://www.stcsig.org/usability/  Usability Toolkit]

== Arquitectura de la Información ==
=== Card Sorting===
===Etiquetado y lingüística===
=== Mapas de Navegación ===
=== Mapas de Interacción ===
=== WireFrames ===
Llamamos wireframe a una representación esquemática de una página web sin elementos gráficos que muestran contenido y comportamiento de las páginas. Sirven como herramienta de comunicación y discusión entre arquitectos de información, programadores, diseñadores y clientes. También se pueden utilizar para pruebas de usuarios. 

Es muy importante '''aclararle siempre al cliente''' qué es un Wireframe, estar seguros de que entiende que ese no es el aspecto final del sitio, sino una mera representación gráfica de su contenido.

'''¿Cuándo se realizan?'''

Una vez tengamos delimitados los objetivos del cliente, las necesidades de los usuarios y los contenidos y funciones de la web; antes de empezar a programar y de crear el diseño visual de la página.
Por tanto, antes de hacerlo, es necesario tener todos los requisitos del proyecto: requisitos de negocio, de contenido, de diseño, de ancho de banda, de software, etc.

'''Ventajas de crear Wireframes'''

Hay dos grandes ventajas, por un lado el equipo y el cliente se centra en el diseño de contenidos y no en el diseño visual, y por otro lado, definiendo la organización y estructura en etapas previas al diseño y programación se evitan cambios posteriores más costosos, reduciendo así costes y tiempos.

Las principales características o ventajas de los prototipos (se refiere a los prototipos en general, no a los Wireframes en particular) según el doctor Granollers son:

* Son formidables herramientas de:
**Comunicación entre todos los componentes del equipo de desarrollo y los usuarios
**Participación, para integrar activamente a los usuarios en el desarrollo.
* Dan soporte a los diseñadores a la hora de escoger entre varias alternativas.
* Permiten a los diseñadores explorar diversos conceptos del diseño antes de establecer los definitivos.
* Permiten evaluar el sistema desde las primeras fases del desarrollo (facilitan la exploración de ideas sobre nuevos conceptos tecnológicos).
* Son esenciales para la documentación, tanto de conceptos funcionales del sistema como de tareas concretas del mismo.
* Son el primer paso para que ideas abstractas sean concretas, visibles y testables.
* Fomentan la iteratividad.
* Mejoran la calidad y la completitud de las especificaciones funcionales del sistema.
* Son herramientas de propósito general, pues sirven para comprobar la fiabilidad técnica de una idea, clarificar requisitos que quedaron “indeterminados” o ver como responde con el resto de la aplicación.

'''¿Qué información debe contener un Wireframe?'''

* '''Inventario de contenido'''. Qué contenido debe estar presente en cada página
* '''Elementos de la página.''' Cabeceras, enlaces, listas, imágenes, formularios, etc.
* '''Etiquetado.''' De vínculos, títulos, etc.
* '''Layout.''' Ubicación, colocación y agrupación de los elementos de la página (cabeceras, pies, navegación, áreas de contenido, titulares, etc.) Muestra la estrategia de navegación y la priorización de contenidos dentro de la página, así como la agrupación en barras laterales, barras de navegación, áreas de contenido, etc.
* '''Comportamiento.''' Mediante notas asociadas a los elementos para indicar cómo se deben mostrar (nº de elementos, visualización por defecto) o definir el comportamiento funcional cunado un elemento se activa (enlace externo, etc.)

====¿De cuántas páginas creamos un Wireframe?====

De la página principal y de los principales tipos de subpáginas o plantillas, entre las que deberán incluirse, una página de formulario, una página de resultado búsqueda y una página de error. Si estamos ante una aplicación deberá incluir una página de ingreso de datos, una página de detalle y una página de listado.


====Errores en la creación de Wireframes====

Hay tres errores típicos:

* Realizar Wireframes demasiado complejos en su forma
* Realizar Wireframes con algo diseño gráfico
* Incluir un exceso de información


Para evitarlos es bueno seguir las recomendaciones de Liz Danzico en "[http://www.boxesandarrows.com/view/the_devils_in_the_wireframes The Devil's in the Wireframes]"
* Amplifica a través de la simplificación:
**El Wireframe debe ser claro, sin diseño, ni iconos, ni color. Por ello Gene Smith propone usar una única figura, un único color y un único tipo de letra. Tampoco es necesario ser tan estrictos, pero ayuda a entender la filosofía del Wireframe.
* Quita los detalles innecesarios: debe contener el mínimo número de elementos necesarios para que no distraigan la atención.
* Anota cuidadosamente pero sólo lo realmente relevante.
Habrá que tener en cuenta además como se va a presentar, si va a ser un entregable deberá ser autoexplicativo por si mismo, pero si se va a presentar personalmente al cliente (como debería hacerse siempre para evitar interpretaciones subjetivas) no necesitará anotaciones tan detalladas.




[[Categoría: Pre Grado]]
[[Categoría: Diseño Gráfico]]
[[Categoría: Lenguaje Computacional]]
[[Categoría: Cursos]]
[[Categoría: Lenguaje Computacional 2]]