
En verdad que esto me viene "como anillo al dedo" por razones laborales. Lo publica Yussef Hassan en el blog del G4 de Sidar y se trata de un Juego sobre el Diseño Centrado en el Usuario pero en una forma lúdica y atractiva. Está diseñado de tal manera que conduce al equipo que esté realizando el levantamiento para el diseño de la aplicación a través de cuatro etapas fundamentales:
- Definición de los usuarios
- Analisis de sus necesidades
- Diseño y evaluación de la aplicación
- Evaluación final del proceso
El juego ha sido diseñado por Muriel Garreta-Domingo, Magí Almirall-Hill y Enric Mor, de la Universitat Oberta de Catalunya, y se llama User-Centered Design. Estoy segura de que me será de gran utilidad tanto para usarlo como para hacer comprender a quienes me rodean de qué se trata esto de los estudios de usabilidad y por qué hay que hacerlos.
Largo título pero es el que obedece puntualmente a uno de los documentos más interesantes que me he encontrado en la noche de hoy. Su título original en inglés es The infrastructure of experience and the experience of infrastructure: meaning and structure in everyday encounters with space y fue sido escrito por Paul Dourish , Genevieve Bell . La versión inicial es del 2005.
Uno de los puntos interesantes que describen en el abstract es el interés por estudiar la relación entre las estructuras y vivencias de los espacios virtuales con los reales, es decir, el traslado entre ellos. Termino de citarlos en inglés:
Whereas computer science and human – computer interaction have previously been concerned with disembodied cognition, they must now look more directly at embodied action and bodily encounters between people and technology. In this paper, we explore some of the implications of the development of ubiquitous computing for encounters with space. We look on space here as infrastructure—not just a technological infrastructure, but an infrastructure through which we experience the world. Drawing on studies of both the practical organization of space and the cultural organization of space, we begin to explore the ways in which ubiquitous computing may
condition, and be conditioned by, the social organization of everyday space.
La experiencia del mundo y la relación con las estructuras que configuran y delinean ese mundo. Suena interesante y por eso lo subo acá, para no perderlo. Si les interesa tanto como a mí, pueden bajar el trabajo completo en pdf .

Esta tarde he estado dándole mucha vuelta en el dilema de qué escribir y conversando con Giovanni Lamarca encontré las energías para darle salida a uno de esos borradores que tienen meses en el apartado de La Coctelera. La conversación se inició porque él me dijo que estaba "diagramando" una web y yo casi que "pego un brinco" en la silla porque, como se sabe, es un tema que me interesa y uno de los que más preguntas me ha producido. Por otro lado, en las últimas dos semanas he estado trabajando de lleno, junto con mi equipo, en la elaboración de una página Web y a mi, quien soy la encargada de toda la primera parte de identificación de necesidades, diseño de la arquitectura de información y bocetos de prototipado, se me han presentado muchas dudas y preguntas al respecto.
Giovanni me preguntaba, dónde termina una página web y esa pregunta, al lado del recorrido del proceso de todo lo que necesitamos para hacerla, me animó a tratar de darle hilación a algunas cosas, sobre todo en lo que tiene que ver con el proceso de planificación, diseño y programación de un espacio web.
Quien lo ve desde afuera puede pensar que es un trabajo fácil, pero son muchas las personas que intervenen y particularmente importante es que quien diseña y quien programa, sepan qué es lo que están haciendo y que tengan una excelente comunicación. Me imagino que es como cuando un arquitecto diseña una construcción: si el ingeniero y los maestros de obra, etc., no comprenden el concepto, haran una construción que quizás se parezca pero que no es exactamente lo que el arquitecto pensó.

Quien diseña, no necesariamente programa y eso probablemente sea una sorpresa para muchos que deben pensar que se trata de la misma persona (a mi me sorprendió). Y justo encontré hace dos días un site que lo que busca es que diseñadores y programadores se encuentren. Las necesidades de uno y de otro no siempre son las mismas, para proyectos específicos. La página se llama Programmer meet Designer y se justifica justamente porque no necesariamente quien hace una cosa hace la otra bien. Por lo general, al menos en Venezuela, escasean los diseñadores web; yo tengo un anuncio desde hace dos semanas para buscar uno y no ha llegado ni un solo curriculo. Tal pareciera que no es una profesión demasiado valorada y es que la verdad es que no necesariamente quien diseña bien para impreso lo hace bien para web, parecieran ser dos niveles distintos.
En la página que menciono, añaden: elaboradores de contenidos y emprendedores tambien son bienvenidos. Una prueba más de que la creación hoy en día tiende cada vez más a ser en comunidades con individuos que no necesariamente están en un mismo espacio físico. Lo importante es no olvidar a uno de los actores más importantes de todo esto, aquél a quien va dirigida nuestra página: el cliente final. Entender sus necesidades es, probablemente, el punto fundamental, después, todo debería fluir bien hasta que logremos transmitir adecuadamente ese mensaje. Allí el reto.

Nueva traducción, esta vez de un artículo sobre los posibles errores en los que podemos caer a la hora de realizar un diseño web. En este caso es una traducción de una traducción. La tomo de 456bereastreet, que, a su vez lo toma de capdesign, una página sueca de diseño que hizo encuestas a varios diseñadores para llegar a este decálogo:
1. No seguir reglas tipográficas básicas
2. Ser demasiado creativo con la navegación
3. Crear un sistema de navegación lleno o saturado (cluttered)
4. Asegurarse de que el site necesita una cierta tecnología para funcionar
5. Pensar que la accesibilidad sólo es para personas ciegas
6. Ignorar los estándares web
7. No pensar en los diferentes navegadores desde el comienzo
8. Basar la estructura del site en la estructura organizacional
9. Usar texto gris sobre fondo gris
10. Saltarse el estudio de la viabilidad
¿Por qué traducir algo como esto? Nunca está de más basarse en la experiencia de otros aunque, igual, cometamos nuestros propios errores y, quizás, a la larga o a la corta, nuestra propia lista.