No podré asistir este sábado a la desconferencia, pero si lo hiciera, esto es lo que os contaría [1] (preparaos que es largo…):
Luis escribía en su excelente resumen de @media que no se oyó la palabra usabilidad en ningún momento y concluía que no es necesario hablar de ella porque debe “venir de serie” en cualquier desarrollo. Totalmente de acuerdo. Es más, esto es algo en lo que venía pensando hace tiempo ya, quizás desde que estoy metido en un mega proyecto que ya va para los dos años de mi vida (el proyecto es mayor, pero es lo que yo he estado en él), en una mega empresa.
En septiembre de 2004 me incorporé en las fases de definición en este proyecto enorme de una empresa de seguros muy, muy conocida. Y casi desde el inicio tenía la sensación de que algo no estaba bien cada vez que alguien mencionaba “usabilidad” en reuniones, mails o discusiones. El problema no era que se hablase de ello, sino que se utilizaba como si fuese un elemento más del producto, como una fase de trabajo… estaba al mismo nivel que la programación o el diseño de la lógica de negocio. Se pasaba del “diseño técnico” a la fase de “usabilidad” y luego a la maquetación. No me cuadraba, pero no sabía bien por qué. Ahora, gracias al comentario de Luis, acertadamente sintetizado por Javier (“La usabilidad viene de serie, señores”), lo he podido ver claro. ¡Eso es! Es que no se trata de aplicar una capa de pintura sobre una pared agrietada, es que la pared debe estar construida ya pensando en que no se va a llenar de grietas…
Recuerdo cuando a fines de los 90 tratábamos de convencer a los clientes de que debían pagar el trabajo de un consultor en usabilidad para que todo fuese bien y la incredulidad de muchos cuando decían “pero vamos a ver… ¿me decís que tengo que pagar más por algo que doy por hecho, es decir, que lo que vais a hacerme esté bien diseñado?” Y claro, había que explicarle que sí, que ese buen diseño implicaba varias actividades que no estaban normalmente contempladas en el proceso de diseño de una interfaz, hasta ese momento limitado al aspecto estético, y que por eso le saldría más caro.
Hoy, que ya hemos aprendido algo, no incluimos “usabilidad” como un aparte dentro de las propuestas comerciales. O al menos, no deberíamos hacerlo. Porque la usabilidad se da por descontada. Es lógico que las interfaces tienen que ser simples de usar, ser amigables y cumplir con todas esas características que tan bien enumerábamos en las presentaciones. La diferencia está en hacer un buen producto, no sólo un producto “usable”.
Volviendo al inicio de este texto, decía que aquí, donde consumo mis horas laborales, eso no acaba de entenderse aún. Y es que el equipo donde trabajo se llama “grupo de usabilidad”, y yo, soy el “especialista en usabilidad”. No pocos problemas me trae eso, porque para algunos soy una especie de Torquemada que tirará por tierra sus desarrollos e ideas geniales en las “auditorías” (palabra atemorizante por excelencia) que me encargan y para otros, un simple charlatán pinta-monas que contribuiré a que el proyecto salga más tarde y los programadores demoren más en hacer su trabajo. Y todo, para que al final salga un producto “que hace lo mismo que antes, pero más lento… con lo acostumbrados que estábamos a trabajar con el 3270 y las líneas de código”.
Y aquí es donde yo tengo que explicar que no se trata de complicarle la vida a nadie, que no es que no tengamos nada mejor que hacer ni que queramos retrasar los desarrollos. Sino que pensamos en los nuevos usuarios, que aprenderán más rápido; pensamos en los mantenimientos de las aplicaciones, que podrán ser hechos por cualquiera y no sólo por el programador original; pensamos en que las aplicaciones podrán ser escalables y que un equipo de desarrollo a miles de kilómetros de distancia podrá crear una, siguiendo las guías de estilo que hemos editado, etcétera.
Pero la dichosa palabrita se nos pega a la espalda y es un lastre. “Los de usabilidad”, “es norma de usabilidad”, “lo prohíbe usabilidad”, “usabilidad te va a auditar”… Así, es francamente complicado explicar que no, que lo que hacemos es diseñar buenas aplicaciones, buenos productos. Y que lo necesitan, igual que como necesitan un buen jefe de proyecto o un buen programador. Que el diseño del producto no es solamente un tema de costes y tiempos, sino de personas, de interacción de esas personas. Esa es la clave, la interacción.
Intento explicarles que lo que importa no es que la aplicación sea bonita, sino que funcione. Que los procesos sean lógicos, que los usuarios tengan aplicaciones que les solucionen los problemas, que se comporte como se espera.
Quizás haré como Luis y voy a intentar eliminar la palabra “usabilidad” de mi discurso. Me centraré en la interacción, en los procesos, en los tiempos (o “tempos”) de la aplicación. Y con ello, trataré de demostrarles que el buen diseño no está reñido con los proyectos ágiles.
Creo, sinceramente, que son precisamente las grandes corporaciones como esta, las que más necesitan de un trabajo serio en diseño de interacción, para que la “usabilidad” no siga siendo un añadido, sino algo de serie.
Como decía al principio, hace casi dos años que estoy trabajando en un proyecto en una empresa bastante grande de seguros, dentro del llamado Grupo de Usabilidad. La misión de este equipo de gente es participar en un gran proyecto de renovación de herramientas informáticas propias. Es decir, el software que hace que el negocio funcione.
Normalmente las grandes empresas, como bancos, aseguradoras, telefónicas y otras por el estilo, tienen sus propios departamentos de informática que trabajan haciendo desarrollos a medida de las necesidades. Es cierto que muchas veces se contratan estos trabajos a empresas externas, pero cada vez es más común que el trabajo se haga en casa. Por motivos básicamente prácticos y de confidencialidad.
Una empresa de seguros, por ejemplo, no encuentra en el mercado un paquete de software que pueda cubrir todas sus necesidades, dada la complejidad del negocio y las particularidades de cada empresa. Eso sin entrar en los intrincados vericuetos de la organización misma (estructura de administración, de ventas, de agentes, etc). Todo ello se traduce en mil y una pequeñas aplicaciones que se van creando a medida que se necesitan. Al cabo de unos años, lo que hay es un desorden absolutamente incontrolable y, lo que es peor, imposible de mantener.
Es en ese momento cuando puede surgir la iniciativa de hacerlo todo de nuevo. De recomenzar, pero contando con pautas estándares, siguiendo una metodología bien pensada y utilizando tecnologías comunes. Para que cuando sea necesario hacer algún cambio o mejora en el futuro, no cunda el pánico al darse cuenta de que el informático que “tenía todo el proyecto en su cabeza” se ha ido y nadie es capaz de meter mano en el código.
Ahora, este tipo de proyectos no son moco de pavo. Plantearse algo así en una empresa con miles de empleados y oficinas por medio mundo, es algo gordo. Muy gordo. Significa pensar en un proyecto que puede –y seguramente lo haga- durar algunos años. De ahí que la planificación y definición juegan un papel fundamental.
En el caso que nos ocupa, la empresa tomó la decisión de renovar sus aplicaciones por completo, migrándolas a un entorno web que permitiese una actualización y mantenimiento más sencillo, a la vez que poder asegurar una homogeneidad de estilo. Antes, cada aplicación adolecía de las “creatividades” individuales de los equipos de desarrollo que habían participado en ellas.
Dentro de este macro proyecto –curiosamente- se contempló la necesidad de contar con gente especialista en usabilidad. Ignoro quién tuvo la feliz idea, pero sin duda que fue una inspiración que ha valido la pena (no así el nombre del grupo).
Lo más interesante de todo este trabajo, más allá de estar en una de las corporaciones más grandes de España, ha sido el constatar la necesidad que tienen este tipo de empresas de tener equipos de diseño dentro.
Principalmente, la participación de gente dedicada al diseño de interacción puede asegurar que todo el proyecto tenga coherencia. Que todo lo que se haga sea homogéneo y que “respire” un aire familiar. Da igual cuántos programadores, jefes de proyecto, coordinadores o lo que sea, estén involucrados. El producto final, siempre parecerá hecho por los mismos. Algo que las grandes empresas de software han entendido hace mucho tiempo ya y que no sé porqué en otros mercados recién se está tomando conciencia de su importancia.
¿Se imagina alguien que los programas de Apple se comportasen todos de forma diferente o que tuviesen estilos visuales distintos entre sí? O el mismo Microsoft Office: si Word, Excel y PowerPoint, por ejemplo, usasen distintos botones, una distribución de menús propia de cada uno y los menús tuviesen diversos nombres para las mismas acciones, sería un caos. De hecho, nadie lo compraría. Pero parece ser que cuando se trata de los desarrollos propios de otras empresas, todo eso da lo mismo.
Un equipo de diseño involucrado desde el principio aporta precisamente eso, la tranquilidad de saber que existe un control de calidad y una definición de estilos y procesos que además, no choca con los principios de facilidad de uso y eficiencia. Que la usabilidad va de serie, en definitiva.
Si esto se hubiese tomado en cuenta desde el principio, si el “grupo de usabilidad” no hubiese sido un extra -compuesto además por personal externo-, se habrían evitado discusiones tan peregrinas como el correcto diseño de un formulario o la necesidad o no de tener mensajes de espera en las aplicaciones que hacen consultas complejas a la base de datos. Nadie pone en duda los dictámenes de un departamento de arquitectura de sistemas o el de metodología, porque están incorporados de base. Ya es hora de que el diseño de interacción lo esté también.
Creo que nuestra tarea, la de quienes estamos trabajando en proyectos similares en empresas grandes, debe ser también convencerles de que incorporen en su trabajo diario el Diseño, así con mayúsculas. Que dejen de verlo como el peluquero que se llama para tratar de arreglar a la novia en el último minuto. El diseño debe estar dentro, ser indiscutible, tener un papel fundamental. Que dejen ya de hablar y discutir sobre usabilidad, porque ya llevamos mucho tiempo en lo mismo como para no darnos cuenta de que si no se lleva puesta, no sirve de nada.
Cuando esto suceda en las grandes corporaciones, habremos dado el principal paso para dejar de hablar de ello. Habremos llegado al punto más alto en la curva de aceptación de un nuevo concepto o idea y podremos, por fin, dedicarnos a lo bonito: diseñar y solucionar los problemas de las personas.
[1]Propongo además, de este modo, la participación asíncrona para todos los que -por motivos personales, geográficos o simplemente estomacales- no podamos asistir.
4 Trackbacks
You can leave a trackback using this URL: http://www.jmarquez.com/2006/06/26/usabilidad-de-serie-en-empresas-serias-lo-que-os-habria-contado-si-fuese-a-la-desconferencia/trackback/
[...] Usabilidad de serie, en empresas serias. Léanlo, por favor. Léanlo. interaction, design, usability Guardar este post en del.icio.us [...]
[...] Sí, señoras y señores, tenemos el gusto de presentarles… la 1ª Desconferencia que se celebra en España. Habrá tigres, leones, forzudos, bailarinas y algún que otro titiritero. Los malabaristas por asuntos mayores no podrán asistir, pero la diversión está asegurada. [...]
[...] Sin ir más lejos, un reciente debate abierto por Joaquín Márquez en su weblog, hablando del abordaje integral de un sitio web en lo que a experiencia de usuario se refiere, me permitió exponer públicamente uno de los debates que desde mi experiencia de trabajo estoy experimentando, y me viene al pelo comentarlo, pues en su origen está la fase de prototipado: ¿quién debe abordarla, el analista funcional de toda la vida, con perfil desarrollador, o un nuevo perfil que se responsabilice y cuente con la formación necesaria para entender la experiencia de usuario como un objetivo principal y estratégico de cualquier proyecto web? En ese punto la fase de prototipado tiene un papel esencial en lo que será la ulterior experiencia de usuario, con todo lo que ello conlleva. No es de extrañar, pues, que sea una fase esta que comento, delicada y casi diría que vital para una planificación y posterior desarrollo del sitio web que tenga todos, o al menos casi todos, los visos de resultar un trabajo que cumpla con las expectativas de los usuarios que son, al fin y al cabo, los que van a aprobar o a suspender el trabajo realizado. [...]
[...] jmarquez.com « Usabilidad de serie, en empresas serias (lo que os habría contado si fuese a la desconferencia) [...]
29 Comentarios
Qué pena que no puedas asistir a Descon01. El tema que cuentas se me hace interesantísimo y creo que haber podido preguntarte cosas en vivo hubiera sido super-enriquecedor.
Felicidades por el post.
Esperemos que con el tiempo, los buenos resultados justifiquen ‘ese tiempo extra’ a los ojos de los incrédulos. Sería fantástico dedicar más tiempo a resolver e innovar en vez de tener que justificar el valor de lo que hacemos.
Magnífico post. Enhorabuena.
PD: ¡Te echaremos de menos en la desconferencia!
Ole, ole y ole. Fantástico texto. Para mi, de cabecera sin duda.
Lo primero, gracias por vuestros comentarios y referencias.
Javi, para eso están estos comentarios. Lo que se quiera preguntar, se puede hacer a través de ello y así reforzamos la idea de “desconferencia asíncrona”
Agustín, todo se andará… es que somos muy impacientes. Este oficio lleva poco tiempo y es cosa de que se vaya avanzando en la curva de aceptación.
Daniel (torresburiel), halagado me siento ¡Muchas gracias!
Documento para leer, subrayar, anotar, comentar y, sobre todo… para enseñar.
Mil gracias
Gracias por escribir este estupendo artículo. Yo también trabajo en una mega-empresa y aunque mi trabajo no tiene que ver nada con el tuyo me siento muy identificado con lo que cuentas.
Añadiría también que otro de los problemas es la falta de comunicación, o que no sea demasiado fluida. Decisiones sencillas pueden tardar mucho tiempo “gracias” a una interminable lista de correos y respuestas de ida y vuelta.
Muy didáctico el artículo… y ánimo con el proyecto
Excelente reflexión, Señor Joaquín. A sus pies…
Qué recuerdos me trae de mis tiempos trabajando para el gran “entre telefónico”. Discusiones bizantinas para definir cuál debía de ser el comportamiento de link contra los hombres de corbata y traje gris.
Cada día tengo más claro que la palabra usabilidad deberíamos borrarla de nuestros diccionarios. No nos trae nada más que quebraderos de cabeza. A lo mejor cuadra mejor “Grupo de Sentido Común”
Enhorabuena.
Felicidades compadre (peaso artículo), la verdad es que ese campo de batalla comenzó hace bastante tiempo en dicha empresa (yo también estuve por allí, para el resto de lectores), y si no me equivoco fue Pablo quien empezó con la propuesta de hacer más “usables” sus aplicaciones.
Por desgracia no es la única empresa que funciona de la misma manera, el otro día tomando un café cerca de Sol oímos a dos curritos (sin querer, eso sí) la típica frase que oíamos por allí “ya me están $%&!!ndo los de usabilidad”, y la verdad ante tal compostura no te atreves ni a decirle nada, claro (y menos sin venir a cuento), pero apena que tengan una visión equivocada del prisma.
Espero y deseo que de aquí a un año cambien las tornas, aunque todo depende de muchos factores, y por mucho que queramos estamos en una maquinaria lenta y poco engrasada.
Un abrazo majete!
Álvaro
Se puede decir más alto pero no más claro, enhorabuena por el post,
Si se puede preguntar… contáis con el perfil de un psicólogo en ese grupo? no he tenido el placer de contar con ningún “grupo de usabilidad” en las empresas que he estado, aunque siempre he visto el tema de funcionalidad-usabilidad como algo incluido en los proyectos, de todas formas… No tiene algo que ver la psicología en todo esto? me refiero inclusive en temas de diseño, tipos, colores… es algo que siempre me ha llamado la atención, el ¿Por qué se separa tanto o se tiene tanto miedo desde la usabilidad al diseño aplicado? (ese sería mi tema desconferenciando
). Creo que todo es un conjunto, todo está sumamente relacionado, el estudio del comportamiento humano es general y en ello tiene algo que ver el tema emocional, los colores son emociones, y también tienen su propia psicología, además y aunque no tenga que ver, sólo como apunte en temas de usuarios, la película “Ice Age” en el que el resultado fue la modificación de un personaje ya que emocionalmente gustaba incluso más que los propios protagonistas. Las emociones influyen en todos los aspectos, ¿Que piensas sobre esto?
Que un coche deba traer de serie frenos para las 4 ruedas no quiere decir que no deba mencionarse y facturarse. No es malo citar la usabilidad como tal o el diseño de interacción, entre otras cosas por la ignorancia del mercado.
Me parece poco argumentado y excesivamente complaciente con los que después han venido a darle a usted palmaditas en la espalda.
César, Gonzalo, Álvaro, Juan, Pixer y Dalesi, muchas gracias.
Pixer, me metes en un tema demasiado amplio que no sé si es este el sitio para hablar de ello. Quizás sí me atrevo a decirte que la psicología debería seguir el mismo comportamiento: venir de serie. No es necesario contar con un perfil de un sicólogo como tal, sino tener los conocimientos de las áreas de la sicología que tienen relación con el diseño de interacción. Un sicólog puede dedicarse a esto, claro, igual que un periodista (mi caso), un dibujante o un programador. Pero la figura es diseñador de interacción, que aplica esos conocimientos… no sé si me aclaro. Y no creo que se le tenga miedo al diseño aplicado, en absoluto… ¿Por qué lo dices? Estoy totalmente de acuerdo y de hecho soy un férreo defensor del diseño emocional. Trabajamos con personas ¿no?
Dalesi, la idea es que tú cites usabilidad como una característica intrínseca, igual que como dices que utilizas una metodología de trabajo efectiva. Pero no como un plus, porque no es algo que puedas pedir o no junto a tu proyecto.
Agustín, no entiendo tu comentario ¿Podrías elaborar un poco más? No veo la necesidad de argumentar nada… no es una tesis, es una reflexión basada en mi experiencia. Y si soy complaciente (¿qué entiendes por ello?), es porque me merecen mi más absoluto respeto y admiración.
Lamento que no lo entiendas…
Quizá debería argumentar usted más su opinión, es bastante simple a la par que carente de razonamiento
Me refería claro está al comentario de Agustin, perdón, se me pasó escribir su nombre
No esperaba que mi comentario contrario a la par que respetuoso provocara rechazo. Me disculpo si se han sentido ofendidos pero me reafirmo en mi planteamiento.
Buenisimo el articulo Joaquin. Supongo que en parte el difusor de la palabra usabilidad por allí fui yo y el impulsor Pablo como ha dicho Alvaro, y esta claro como tu cuentas, que a larga es una losa.
Te hago una pregunta desde tu experiencia allí. ¿Que palanca harías tu para poderte incluirte desde fuera en esa escala de proyectos tan grandes y potentes? Tengo sensación que la palabra “diseño” dentro del sector IT esta digamoslo así “pervertida” y no sé si va a ser recuperable para poder utilizarla como concepto, sin que se vuelva a cuarto de kilo de diseñador.
Lo dicho, enhorabuena por tu articulo y por tu trabajo allí.
Ya, es una duda que yo también tengo… En este sector (me refiero a la informática) es pelín complicado introducir conceptos nuevos y peor aún conceptos que tienen una concepción tan arraigada en las mentes.
Sin embargo, creo que si se acompaña diseño con algo más, puede funcionar. No olvides que dentro de los proyectos enormes existe el “diseño técnico”, el “diseño funcional” y el “diseño de lógicas de negocio”.
Aquí lo que hemos intentado es introducir nuestras tareas dentro de la metodología de desarrollo propia de la casa, en una fase muy temprana de la definición inicial. No ha cuajado del todo, en parte porque el desarrollo ha debido hacerse más rápido que la definición de la metodología y en parte porque ni los propios metodólogos acababan de entender bien lo de “usabilidad”.
Quizás si tratamos de incluirlo como “diseño de solución”, mano a mano con el diseño funcional, podría ser mejor entendido y, por ende, aceptado. Sonaría menos a “intrusismo”; claro que para ello, quien se dedicase a esto en empresas de gran calado, tendría que tener conocimientos técnicos que le permitiesen hablar al mismo nivel con los analistas más “duros”. Puede que el profesional del diseño de interacción también tenga matices y un mismo diseñador de interacción no valga igual para proyectos de aplicaciones que para proyectos con una vertiente más visual/estética o de comunicación… ¿Opiniones?
“Sin embargo, creo que si se acompaña diseño con algo más, puede funcionar. No olvides que dentro de los proyectos enormes existe el “diseño técnico”, el “diseño funcional” y el “diseño de lógicas de negocio”.”
Sin duda para estar ahí tiene que ser de esa manera, sumado a la metodología y con una capacidad alta de interlocución con el resto de las partes.
Eso si, lo veo complicado, la relación de lo tecnico con lo funcional esta tan instalada en algunos sitios que veo complicado introducir esa figura que en el fondo se tendría que encargar de poner a las partes deacuerdo.
Haciendo un proyecto similar para otro departamento de IT en el que igualmente se quería una guía para estandarizar el diseño y los recurso de interacción, la guía se preparo para los analistas funcionales. Es una pasada, pero me llevo a la reflexion de si no es donde se tendría que ir a ubicar un diseñador de interacción y donde se deberían ubicar los equipos de diseño.
El caso es que, desde que trabajo en medios interactivos (procedo de los medios impresos) me he encontrado gran ignorancia en lo que a diseño se refiere. El hecho de que se acuñe un barbarismo como “usabilidad” ha permitido que las mentalidades evolucionen y entiendan la importancia del diseño orientado al usuario, que es exactamente lo que se hace en los medios impresos. De hecho, al diseñar sitios web, interfaces de aplicaciones y demás, nunca he tenido la sensación de estar haciendo nada distinto (en lo fundamental, se entiende) de lo que ya había hecho para soportes de papel.
Suscribo lo mismo que han dicho sobre este artículo la mayoría, por no poner todos los nombres. Gracias. Yo también trabajo en una entidad de este estilo, y desde mi punto de vista de desarrollador (analista cuando toca, pelacódigos el resto del tiempo) es un tanto frustrante ver que por parte del resto de la cadena de producción de software no hay esa visión de hacer las cosas con sentido común, y pensando en el usuario. Asi pasa. De esto es también de lo que me gustaría a mi hablar en la desconferencia del sábado.
Respecto a lo de incorporar una visión psicológica en los proyectos informáticos, creo que es fundamental. Hace unos años me plantee estudiar sociología o psicología justo por este motivo pero desgraciadamente no hay tiempo para todo.
En una entidad mediana, cuyos usuarios del software que produces son tus propios compañeros, está mas clara quizá esa sensación de “compañerismo o complicidad” a la hora de acometer los desarrollos de software precisamente porque nos conocemos.
Si la intención es esa, ¿Porqué a veces se queda en intención? Es necesario escuchar a todas las partes afectadas en un desarrollo y si va a tener una duración o intensidad fuera de lo normal, se toman medidas psicológicas por parte de recursos humanos: incentivos, vacaciones, etc.
Ahora vamos a la parte final de un desarrollo: Sacar partido al sistema. Si esto no es posible, por cualquier motivo, sea o no relacionado con la usabilidad, el usuario se sentirá frustrado y esto redunda en el entorno. Atenderán peor a los clientes, o tardarán demasiado, o tendran que echar horas para cuadrar, o no encontrarán la circular sobre el ensobrado de cheques y enviarlos mal costará dinero a la empresa, etc.
Son muchas las cosas que hay que pulir cuando el usuario es un usuario “obligado” a utilizar tus herramientas porque no hay otras. Precisamente si hacemos aplicaciones para nosotros mismos, ¿Porqué no tener en cuenta la mejor manera de sacarle partido? A veces por creer que sabes lo que necesita el usuario, a veces por falta de formación, a veces por confiar en una consultoría que sale rana, a veces por que “los de arriba” no ponderan bien los elementos en juego…
El problema reside en que cuando a uno le convierten en el apagafuegos oficial termina creyendo que sabe utilizar la manguera. Este es un problema que afecta a buena parte de los proyectosy que necesita los máximos recursos para cambiar. Por ello la formación debería dirigirse a la especialización de perfiles integrados (sin perjuicio de que la multidisciplinariedad es cada vez más necesaria).
muy enriquecedor el artículo, joaquín.
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.
Dependiendo del soporte se estudia el diseño, ¿no?
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
Con esto me refiero que el estudio del usuario no es algo nuevo inventado con la aparición de internet, y es algo tan del día a día que debería estar presente sin ser comentado, lo que pasa es que hoy en día debe decirse para que se convierta en costumbre.
Joaquín, no sé si saldrá el trackback. Por si acaso, una idea al hilo de lo que cuentas y de los nombres y títulos:
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
Javier, estoy de acuerdo contigo. Sin embargo, creo que lo de analista funcional tampoco sirve como etiqueta. Me explico: sí que es esa la función que hay que desarrollar, pero al etiquetarte como tal se te tiran al cuello los “analistas de toda la vida”. Ten en cuenta que en informática el ser “analista” es un grado que se gana con experiencia y méritos y conlleva, entre otras cosas, un estatus jerárquico. El analista es más que el programador.
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.
Yo sí que estoy de acuerdo con Javier, y pese a que las cosas son como dice Joaquin, que los analistas de toda la vida se te tiran al cuello, hay lineas argumentales que, junto con la “voluntad política” de los jefes, hacen que sea ineludible la responsabilidad de los -vamos a llamarlos- “diseñadores de interacción” en cuanto a esa labor.
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.
Correcta la reflexión de Joaquin de que la etiqueta no sé si valdría.
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.
Felicidades Joaquin por el artículo; muy bueno.
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.