Sólo quería decir que creo que Torresburriel da en el clavo al hablar del usuario como figura que se situa en el centro de todo.

Desde mi posición de currante en una de esas grandes compañías, me doy cuenta de que todos los desarrollos (tanto de aplicaciones de uso interno como de aplicaciones para el cliente; y tanto si se trata de proyectos de mantenimiento como de desarrollo de nuevas soluciones) habrían de integrar la “perspectiva usuario” de forma transversal en todas las fases metodológicas.

Para una gran compañía cuyas aplicaciones son usadas por multitud de personas, creo que resulta esencial que ésta disponga y gestione la información relativa al comportamiento de sus usuarios.

Estoy de acuerdo contigo en que lo ideal sería contar con un Departamento de Diseño de Interacción; integrado en el de Tecnología, en el que hubiese perfiles técnicos y de negocio; y donde se analizásen estadísticas de uso, e-mails de opinión, incidencias técnicas, resultados de tests, tráfico, encuestas, …y cuanta información sirviese para conocer quienes son las personas que están detrás de la máquina y como se comportan con ella.

Me gustaría saber si hay alguna gran compañía en este país que dedique sus recursos de esta forma. Me imagino que ninguna o casi ninguna (que no sea una .com).

Y creo que la explicación hoy está en que las empresas no ven justificada una inversión de este tipo ya que no resulta algo “básico” para su negocio y, por tanto, optan por externalizar. Y como lo que se externaliza son los proyectos (no el todo), darle al “diseño de interacción” un protagonismo global en la compañía resulta poco menos que imposible.

Ojala vosotros, profesionales de estas disciplinas, logréis invertir las tendencias.

Además en casos como el de los seguros o por ejemplo la distribución, la complicación del negocio es tal que el perfil se complicaría muchisimo, un diseñador de interacción que sepa de negocios de seguro puede ser cuasi imposible de encontrar.

Desde luego la venta si que tendría que ir por hacerle la vida más facil a los analistas funcionales en su interlocución con la parte técnica, que suele ser tormentonsa.

El caso que yo conozco, vivo, padezco y disfruto es el de la empresa donde trabajo, en la que está empezando a implantarse esa metodología y esa asignación de responsabilidades. Y sí, es complicado hacerse con las riendas, pero si hay “voluntad política” desde arriba, todo es más llevadero.

Una de las frases que he escuchado por la oficina es que “la interacción con el usuario no la puede hacer un perfil programador por tal perfil. Punto”. Y no tengo nada que objetar. Más bien levantarme y apludir.

Quizá, en el fondo, se trate de interiorizar a nivel organización el objetivo de los desarrollos. Son los usuarios, ¿no? Pues eso.

Mi artículo va en la línea de cómo integrar nuestra labor dentro del marco de trabajo normal de una empresa de grandes dimensiones, donde hay parcelas ya establecidas, reductos “feudales” que son inexpugnables y un sinfín de personajes que basan su felicidad en el título que ostentan y en tener plaza de garaje.

De eso se trata, de ver cómo hacer que:
1.- entiendan que el diseño de producto/usabilidad/analisisfuncional/como sequierallamar es básico e indiscutible
2.- el perfil de quien desarrolle esas facetas del trabajo tiene tanta importancia como los demás y es un factor clave en el éxito de los proyectos, sobre todo en los a gran escala.

El truco para integrar la usabilidad en los equipos clásicos y hacerlo DE VERDAD está en no ser auditores, sino en ser… ANALISTAS FUNCIONALES. Esa es “su” palabra. Analistas funcionales que saben algo de diseño. Jorge Tercero, nuestro tecnosensei en 11870.com, lo dice a menudo: el análisis funcional lo hacéis vosotros. Aunque está por ver que eso vaya a funcionar, claro

Eres un cliente y tienes varios proyectos debajo del brazo:

1- Necesitas un sitio web
2- Una aplicación para tus empleados
3- Version multimedia de como enseñar a nivel marketing tu producto.

1- Sitio Web usable-accesible-funcional, etc… pero metiendos más en el barro del tema gráfico-emocional ya que aunque no sea el tema más importante si que es un valor añadido.

2- Una aplicación será a grandes rasgos muy usable y funcional pero sin centrar el tema gráfico ya que no vendemos a sus trabajadores.

3- El marketing, es más visual y por tanto un proyecto multimedia es más centrado en que el comercial de turno sepa cómo transmitir lo bueno que es tu producto, siempre desde un soporte que destripe a nivel gráfico lo superchupiguay que es.

Y bueno… que narices! cuando entras en un Supermercado accedes a un “Gigante Google”, absolutisisisisimamente todo está estudiado, te costará más dinero si posicionas tu producto a buena altura de un stand, o si está en depende que parte o sección del local, nos estudian donde miramos, donde paramos, donde poner y a qué altura los productos dulces para niños y que estén en su ángulo de visión, no os habeis preguntado ¿Por qué narices se menea el carrito de lado?, :p

en algunas partes me ha hecho redordar muchas de las opiniones que se manifestaron en “tendiendo puentes entre la interacción persona ordenador y la ingeniería del software”, un interesante workshop que tuvo lugar a finales del año pasado en la upm y en el que pude participar.

en ese workshop se habló mucho de usabilidad en proyectos “gordos” y, desde el primer momento, todos estuvimos de acuerdo en diferenciar una usabilidad “de primer nivel” (cercana al diseño de producto) y otra “de segundo nivel” (cercana al diseño visual).

la de primer nivel, obviamente, es la más compleja, la que afecta a la estructura, la menos mecanizable y la que producía más enfrentamientos. ¿el problema? siempre el mismo: los requisitos, ¿quién define los requisitos? ¿alguien que desconoce el alambicado sistema de engranajes que sustenta aquello o alguien que desconoce cómo se va a usar y a quién va dirigido?

ante esa problemática (la punta del iceberg de las problemáticas de los proyectos “gordos”) me parece no ya interesante sino necesario el intentar fomentar ese perfil de “diseñador de soluciones”, “diseñador de interacción en productos digitales”, “diseñador de sw”, “diseñador informático” o como se le quiera llamar. un perfil, en efecto, simétrico al de analista funcional.

yo he tenido (y estoy teniendo) algunas experiencias de ese tipo y la cosa no va mal. tal vez echo en falta un poco más de autoafirmación, de que a la gente no le extrañe mi presencia, pero -en fin- eso es algo que podemos mejorar.

de algunas de estas ideas intentaré hablar en la descon01, a ver qué tal.

por último, sólo objetar que yo no desterraría la palabra “usabilidad” (como la que no afecta de manera tan directa al diseño del producto). entendida de una manera nielseniana, de una manera de buenas prácticas, es algo que no está de más y, además, es relativamente fácil de chequear, testar y validar. que no es poco.