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.

Toda vez que vamos a diseñar un site o publicación, a escribir algo o a comunicarnos con alguien, uno de los aspectos más importantes que tenemos que recordar es, justamente, que existe un alguien a quien nuestro discurso, o diseño, va dirigido.
Desde hace unas semanas he tenido archivado un post del cual éste parafrasea el título. Se trata de un artículo escrito por Jane McConnell y titulado "From From producer logic to user logic: the greatest challenge you may have.
Pensé, inicialmente, comentarlo, pero me parece tan interesante que decidí escribirle a la autora, quien amablemente me autorizó a que lo tradujera. Habla sobre el desarrollo de Intranets pero creo que puede ser extrapolado a cualquier proceso de diseño digital. Thanks, Jane!

De la lógica del productor a la lógica del usuario: el reto que debes tener

Cambiar la estructura de una intranet de una lógica de producción a una lógica de usuario es, probablemente, una de las tareas más difíciles que le toca hacer a un administrador de intranet, sobre todo en organizaciones grandes y complejas.
Las intranets tienden a comenzar con una página por departamento, una págna por unidad de negocio, una página por función, etc. Incluso encontrar a alguien que pueda encargarse de cada una de ellas puede ser difícil.
Muchas intranets han sido iniciadas con esa estructura. Y no es sorprendente. Personalmente creo que era la única manera de hacer funcionar grandes intranets. Conenzó a ser un asunto de orgullo y de visibilidad: yo tengo un site, yo existo.
Uno de los principales problemas de estos sitios era la mezcla de información y servicios para los miembros de los departamentos, sus proyectos, las noticias "internas" y actualizaciones, con la informción y servicios que el departamento proveía a otros empleados. "Nosotros para nosotros" y "Nosotros para ellos".
¿La intranet fue diseñada para proveer servicios a otros empleados o para satisfacer las necesidades de los miembros de esa función o departamento?
Adicionalmnete a esta confusión, y ante la proliferación de sitios, los gerentes decidieron implementar una así llamada Página Web Global (Global Home Page)
Enseguida se inició la competencia por un espacio en el Home Page. El premio mayor era tener una pestaña en la barra de navegación principal.
Moverse de una situación de ese tipo a una estructura que siguiera la lógica de los usuarios, pone de manifiesto una cantidad de elementos:

* Primero, usted debe saber qué es lo que los usuarios necesitan.
* Después usted debe definir los ítems de navegación primaria - el nivel superior de todo el contenido de la intranet.
* Entonces, usted debe encontrar responsables para cada sección, y allí es donde radican las dificultades.
Por ejemplo, si usted tiene secciones llamadas Servicios a Empleados, Información de referencia o práctica, ¿quién sería el certificado para asegurar que ellas llenan las expectativas de los empleados? Estas categorías no caen naturalmente bajo la responsabilidad de determinados departamentos o funciones.
Estas secciones serán alimentadas por varias fuentes de información, manejadas por distintas personas, departamentos y funciones. Cada proveedor será responsable de la calidad de su información.
Pero ¿quién tiene la mayor responsabilidad? Y más truculento: ¿cómo le explicas a el o la jefe(a) de un departamento que su información no estará ya en una página individual, sino que estará distribuída entre diferentes sitios ,ninguno de los cuales será "suyo"?
De repente, este departamento perdió visibilidad. Esto puede ser políticamente difícil ¿Cuál es, entonces, la respuesta?
Varios puntos me vienen a la mente:

* Una estructura de intranet negociada, o lo que yo llamo una "auquitectura de usuario" con un limitado número de categorías de alto nivel que deben ser definidas y acordadas por un grupo de trabajo en el que estén representadas la mayor cantidad de funciones y departamentos.
* Los miembros de este grupo de trabajo deben tener una jerarquía tal en la organización que puedan tomar decisiones, y que estén lo suficientemente cerca de los usuarios, y de las operaciones, de manera de comprender lo que la gente necesita.
* La arquitectura de usuario debe ser aprobada a un muy alto nivel de la organización.
* La responsabilidad por las secciones, así como para proveer contenido deben ser incorporadas dentro de las definiciones de rol de los empleados.
* Debe dársele visibildad, tanto a los productores de contenido, como a los que gerecian las secciones.

En una organización global, definir el nivel más alto de la arquitectura puede tomar, a veces, meses de discusión, docenas de conferencias web y telefónicas entre los miembros de los grupos, y dos o tres rondas de propuestas.

Pero al final valdrá la pena. La decisión final tendrá un mayor chance de ser implementada, mantenida y comprendida.

No he hablado sobre las pruebas (testing), que, por supuesto, deben ser hechas a toda escala antes de finalizar y proponer cualquier estructura.

Tampoco hablé acerca de cómo la asistencia de un facilitador externo es fundamental, si el contexto es altamente complejo y político. ¡Estos serían buenos temas para otro post!

Encuentro una interesante noticia en Xataka: La mitad de los gadgets devueltos no son defectuosos. ¿Qué tal? Por supuesto se trata de que el 50% de los equipos electrónicos que los usuarios devuelven a las tiendas donde los compraron están perfectamente bien pero, de una u otra manera, no los supieron hacer funcionar bien.
¿Neófitos tecnológicos? ¿Francamente incultos? ¿Torpes? Por allí podemos seguir. Probablemente todos ellos, o la gran mayoría, se habrán dicho eso mismo y se habrán lamentado de no ser capaces de interactuar con un aparato con el que la mayoría si puede, y al primer intento.
Me puse a buscar y me di cuenta de que no es fácil conseguir información al respecto. Cada vez hay más documentos sobre accesibilidad web, pero la pregunta ahora tiene que ver con la realidad cotidiana y la interacción con los distintos objetos con los que interactuamos día a día.
El punto me lleva a varios temas. Con respecto a ellos algunas anotaciones:
Los manuales
Todo equipo, gadget o aparato que nos compremos debe venir acompañado con un manual de uso, pero me gustaría saber cuántos usuarios realmente se los leen. Mi experiencia es que se va al apartado del manual que se necesita en un momento determinado pero se parte de la idea de que éste no es necesario y que no debe serlo. "Debería saber usarlo sin ayuda" es lo primero que se tiende a pensar. El aparato, equipo, lo que sea, debería ser lo suficientemente "comprensible" (accesible) para que nadie tuviera que decirme cómo usarlo. Como vemos, la realidad no es asi.
Estética y usabilidad
Continuando con la búsqueda acerca de la relación diseño Vs usabilidad, que es uno de los temas resaltantes en todo esto, leo en la página de Nilsen un artículo titulado When Good Design => Bad Product, que comienza diciendo:

Qué extraña situación. Usted toma un producto mediocre y retrabaja el diseño para hacerlo mejor. Su diseño es un éxito, en todo sentido, pero el resultado de funcionalidad es peor. Usted redobla sus esfuerzos pero parece inutil. No importa cuan brillante o efectivo sea su diseño, en la medida que se mejora el producto, menos usable se convierte.

Ergo, no necesariamente el diseño más atractivo nos brindará la mejor experiencia de usuario.
Cognición, emoción y usabilidad
Me parece pertinente aca recordar los tres niveles del sistema cognitivo y emocional que menciona Donald Norman en su libro El diseño Emocional: visceral, conductual y reflexivo. El mismo Norman da un ejemplo muy claroen un artículo cuando habla del reloj Jensen . Se trata de modelos de relojes en los cuales el diseño está por encima de la utilidad. Se venden en el Museo de Arte Moderno de Nueva York y, de hecho, parece que muy pocos habian intentado probarlo. En una prueba de usabilidad una mujer se encontró tan frustrada por no poder usar el reloj Jensen que se encontraba al borde de las lágrimas y el equipo la disuadió de que no siguiera intentándolon y pasaron a otro producto; sin embargo, la mujer intentaba nuevamente con ese reloj y decía: "Me muero por comprarlo. Pero no podría. No pude usarlo y aunque quisiera no podría comprarlo. Eso es demasiado mal". Frustración total y peor aún cuando el manual no podía ayudarla, a pesar de los intentos. Una segunda mujer (más cognitiva, según Norman) si pudo leer la hora en el reloj, pero solo despues de descifrar el manual. Total... un desastre: el producto era "cool" para todos, una maravilla de diseño pero no habia manera de usarlo. Para colmo, era muy caro.
Ya ven, no es tan sencillo y por eso es que son interesantes y poderosas estas pruebas de usabilidad. Los objetos cotidianos, al menos los que nos sirven para resolver efectivamente la vida diaria, satisfacer nuestras becesidades "primarias" deben funcionar bien o, dicho de otra manera, deben estar hechos de tal manera que interactuemos efectivamente con ellos sin tener que andar con un librito de consulta todo el tiempo.

Noticia en Gizmodo
Más sobre Donald Norman
Entrevista a Donal Norman por Javier Cañada y Marco van Hout
La página del grupo de los tres gurús de la usabilidad: Nielsen, Norman y Tognazzini