índica. océanos de contenido » Search Results » diseño+centrado+en+la+actividad

2008: Recap of the year

seisdeagosto — Sat, 27 Dec 2008 15:55:15 +0000

2008 has been a hard year but, despite all the economical issues we are living, I have to say that this year says goodbye with a real happy feeling. This is the first time Índica writes a year recap, happy feelings provoque this kind of reactions…

2008 (Sept) was the starting point of my personal project: Seisdeagosto.com, providing Interaction Design and Consulting services. 2008 was also the year when this digital farm decided to try to write in English (July).

During this year we´ve visited the following countries: from Spain to Romania, Italy, Greece, Finland, Estonia, USA, France, Germany and Portugal.

Last november Índica made 4 years, with 279 posts so far. Below I´ve selected some of this year:

January

February

March

April

May

June

July

August

September

October

November

December

I just can´t stop thinking about the things 2009 will bring us. I think is going to be a challenging one. I also wish a challenging year for the loyal readers sometimes bother to read what we write here.

Happy 2009!

Diseño centrado… ¿En el usuario o en la actividad?

seisdeagosto — Tue, 15 Jul 2008 11:55:07 +0000

La conocida expresión “escucha a tus usuarios”, pilar central del diseño centrado en el usuario, puede llegar a tener su vertiente negativa, sobre todo en aplicaciones muy específicas.
Los tests con usuarios, una de las principales técnicas de este enfoque, se desarrollan en escenarios ad hoc, donde tus usuarios se ven “forzados” a comentar en voz alta y la necesidad no es real, sino figurada. De estas pruebas surgen opiniones, muchas veces condicionadas y, a veces, contradictorias. Cuanto más bases tus decisiones en los gustos de una determinada población menos apropiada será la solución adoptada para el resto.

¿Diseño centrado en el usuario o diseño centrado en la actividad?
Dependiendo del tipo de aplicación que estés definiendo, con el diseño centrado en la actividad podrás sacar conclusiones más interesantes a la hora de definir una interfaz.

Estudiar al detalle para qué actividad sirve la interfaz que estás desarrollando y cuáles son las tareas implícitas de dicha actividad es casi más importante que conocer a los usuarios que van a utilizarla. Conociendo en profundidad lo primero tienes prácticamente ganado lo segundo: Qué usuarios van a usar lo que estás definiendo.

Pero… ¿Qué es la actividad?
La actividad es muchas veces confundida con el término tarea. En realidad tarea es una subdivisión de la actividad. Podríamos decir que la actividad está compuesta por un conjunto de tareas. A su vez, estas tareas agrupan un conjunto de acciones y estas acciones están formadas por un conjunto de operaciones. La unión de tareas + acciones + operaciones da como resultado final la actividad desarrollada por el individuo.

En otras ocasiones ya hemos hablado de que no es lo mismo la tarea prescrita (la que se supone que tiene que desempeñar el usuario) que la tarea real (aquella que realmente desempeña, basada en la experiencia individual, con sus atajos, trucos, etc…) y este detalle también es necesario tenerlo muy en cuenta a la hora de abordar un diseño centrado en la actividad.

Un ejemplo.
Conducir un coche (actividad) engloba un conjunto de tareas (girar el volante, meter las marchas, frenar…). A su vez, cada una de estas tareas llevan implícitas un conjunto de acciones y operaciones (para frenar hay que levantar el pie del acelerador, apretar poco a poco el embrague, meter marchas más cortas… ).

Lo más curioso del ejemplo anterior es que la fabricación de estos coche no se basa en test con usuarios (Crash test dummies aparte). Es algo que ha ido evolucionando y mejorando a lo largo de los años, generación tras generación. Sin embargo, gracias al profundo conocimiento adquirido de la actividad los coches evolucionan y mejoran constantemente. Este tipo de diseño evolutivo, que va a pasando de generación en generación Norman lo denomina Folk Design.

Conclusiones.
En aplicaciones muy específicas tu interfaz no puede ser estática y simplemente adaptarse al “Libro de Estilo”. Tiene que ser una aplicación dinámica, vital, muy adaptada al conjunto de tareas que tus usuarios desarrollan en un entorno muy específico. Además de estar frente a una pantalla tus usuarios también realizan tareas paralelas, muchas veces apartados de dicha pantalla, de las que depende el éxito final de la actividad.

Christine Frederick en su libro “The Labor-Saving Kitchen” (1919) observó lo siguiente: “We find that work in the kitchen does not consist of independent, separate acts, but of a series of inter-related processes”.

Simplemente eliminando las palabras “in the kitchen” que Christine menciona en el texto anterior el enfoque es, si cabe, más potente, consolidando aún más su observación.

Quien quiera indagar más sobre el tema recomiendo una pausada lectura de los siguientes artículos, fuentes de inspiración de este post:

Human-Centered Design Considered Harmful (Don Norman)
HCD harmful? A Clarification (Don Norman)

Desarrolladores vs. diseñadores gráficos en el diseño de interacción

seisdeagosto — Tue, 11 Oct 2005 08:53:21 +0000

Dos enfoques distintos que producen dinámicas de trabajo diferentes a la hora de crear interfaces de usuario fáciles de usar.

La actividad del diseñador de interacción no sólo se limita a generar propuestas de interfaz. Revisar cómo se implementan los prototipos en la propuesta forma también parte del día a día de los que se dedican a crear procesos fáciles e intuitivos.

La revisión de prototipos implica realizar un seguimiento de los bocetos definidos y ver cómo se han implementado en la propuesta final que toque, maqueta, conjunto de PSD´s, etc.

No se trata tan solo de identificar posibles oportunidades de mejora en los flujos de navegación que se generan entre las diferentes pantallas, también hay que repasar la aplicación correcta de etiquetas, errores en el diseño, etc… Se trata, en definitiva, de comprobar que lo que se ha definido en el prototipo funciona y se aplica según lo previsto.

Esta tarea de revisión de prototipos es un diálogo que se genera, según sea el caso, entre dos perfiles:

Diálogo 1. Entre el diseñador de interacción y el diseñador gráfico. Este último, tras definir la capa de diseño entregará su propuesta al equipo de desarrollo.

Diálogo 2. Entre diseñador de interacción y uno o varios desarrolladores, cuando no existe un perfil de diseñador gráfico propiamente dicho.

La dinámica de las reuniones entre el diseñador de interacción y el que implementa el prototipo, ya sea diseñador gráfico o desarrollador, son muy diferentes dependiendo del perfil.

Diálogo 1. Diseñador de interacción con diseñador gráfico

Un diseñador gráfico atiende más al diseño visual, presta más atención a la organización de los módulos que componen una determinada propuesta gráfica: el código de color empleado, la tipografía, alineaciones, retículas, etc.

Elige una propuesta gráfica y aplica esa identidad visual a lo largo de todas las propuestas de interfaz definidas por el diseñador de interacción.

Al estar más centrados en aspectos visuales, los diseñadores gráficos suelen dejar de lado aspectos de navegación o comportamiento, y es aquí donde el diseñador de interacción tiene que prestar una mayor atención a la hora de identificar áreas de mejora:

Diálogo 2. Diseñador de interacción con desarrollador

Existen corporaciones donde el perfil de diseñador gráfico, o no se considera o por distintas razones, no se implica en un determinado proyecto. Las propuestas de interfaz en este caso, pasan del diseñador de interacción al equipo de desarrollo, que hace las veces de “desarrollador y diseñador gráfico amateur”.

Cuando el que implementa la propuesta generada por el diseñador de interacción es un desarrollador, existen más posibilidades de que se dejen pasar detalles como alineaciones, colores, distancias entre elementos, etc… Pero, por el contrario, aspectos de navegación y comportamiento se aplican de forma sólida.
Conclusiones:

Los aspectos en los que el equipo de diseño de interacción debe intervenir con un diseñador gráfico son muy diferentes a aquellos que se tocan cuando se trabaja codo con codo con un desarrollador.

Con un desarrollador las áreas de mejora están más relacionadas con el diseño visual (estética). Lo contrario ocurre con el diseñador gráfico, que deja pasar de lado más detalles que tienen que ver con navegación o comportamiento de interfaz.

La opción de pasar un prototipo directamente a desarrollo parece, desde mi experiencia, ser la solución más interesante, ya que el primer objetivo es que la página funcione y se comporte correctamente y, más tarde, aplicar conceptos de diseño visual.

A nivel práctico creo que una formación en desarrollo complementada con conocimientos de interacción sería lo más razonable o con más posibilidades de funcionar. En una situación real es mucho más necesario y urgente que un sistema funcione de manera coherente y lógica, que su atractivo a nivel visual.

En algunos casos, cuando he visto el trabajo del diseñador gráfico sobre mi propuesta de prototipo realizada unas semanas atrás, he tenido dificultades en identificar que realmente era mi propio prototipo.

Trabajando con desarrolladores la experiencia ha sido diferente, no sólo veia claramente el prototipo desarrollado por debajo, sino que también identificaba más rápidamente qué cosas había que seguir mejorando para avanzar con la propuesta. El diseño se aplica de forma más rudimentaria pero lo que va apareciendo es más coherente.

Este artículo no pretende polemizar sobre qué formación o perfiles son más adecuados, ni quién es mejor. Tan sólo trato de plantear soluciones a un problema que seguramente muchos de nosotros, tenemos día a día.

No related posts.