Independiente de la metodología que se aplique para el diseño y el desarrollo, ésta es una pregunta que debe estar presente en las discusiones sobre lo que se requiere diseñar.

Esto no parece un trabajo que presente mayores dificultades desde el punto de vista del diseño centrado en el usuario dado que es un cuestionamiento que viene incorporado en los principios de esta metodología. Sin embargo, se presenta un problema cuando los principios básicos  de la arquitectura de la información, usabilidad y accesibilidad se ven amenazados por la utilización de otras metodologías, cuando no es considerado el trabajo de investigación de usuarios ni de documentación del proceso de diseño.

Ante esto y como conclusión quiero recordar algunos conceptos y hacer una recapitulación, tanto de lo los últimos tres post como de mi experiencia personal trabajando en este tema.

Acá va:

• Las metodologías de desarrollo ágil son compatibles con las de diseño centrado en el usuario si los equipos las conocen a cabalidad.
• Para aplicar metodologías de desarrollo ágil no es necesario seguir al pie de la letra lo que dicen los libros, dado que no todos los proyectos ni los contextos son iguales.
• Las maquetas y las definiciones de las necesidades no pueden salir de la imaginación del equipo de diseño ni del equipo de desarrollo, es importantísimo hacer investigación de usuarios, particularmente cuando se trata de desarrollos transaccionales complejos.
• Juntar diseño centrado en el usuario y desarrollo ágil puede ser catastrófico si no se está consciente que las definiciones del negocio deben ser concebidas antes y no durante el proceso de desarrollo.
• De nada sirve hacer investigación de usuarios si en el proceso esto se diluye.
• El diseño no se puede discutir en los sprint, debe ser un tema que esté cerrado y testeado con usuarios antes de que se comience con el proceso de desarrollo.
• No hay que perder de la vista que el diseño es centrado en el usuario, no en el desarrollador.
• Si bien en el desarrollo ágil se trata de disminuir la excesiva documentación, es necesario documentar el diseño, aunque sea fuera de este proceso, con el objetivo de no comenzar el diseño de cero en un sprint.
• Las maquetas deben ser testeadas con usuarios antes del desarrollo, o más bien, antes del primer sprint.

La experiencia de usuario debe ser vista como una política institucional. Poco se logra si no toda la institución está orientada a aumentar los niveles de satisfacción de los usuarios.

Relacionados:

• Llevando el Diseño Centrado en el Usuario al desarrollo ágil I
• Llevando el diseño centrado en el usuario al desarrollo ágil II.
• Llevando el diseño centrado en el usuario al desarrollo ágil III.

“…
El desarrollo ágil es bueno para la refinación, no para su definición

Si tiene un producto que ya existe y que quiere desarrollar a un nivel superior, el desarrollo ágil funciona porque ya tiene una base sobre la que aplicar mejoras.

Esto significa que si usted ya sabe lo que necesita y los requerimientos ya han sido definidos y debidamente obtenidos (desde una correcta investigación del usuario, desde el análisis comparativo, desde la persperctiva de los objetivos de negocio, y el análisis de contenido) puede perfectamente lograrse desde el punto de vista técnico.

Pero gastar dinero en el desarrollo de software sin un plan de lo que se quiere construir es como pedirle a un equipo de construcción que construya una torre sin ninguna planificación.

Diseño Centrado en el Usuario

El diseño centrado en el usuario requiere iteración, diseñar, probar y testear con usuarios, perfeccionar, probar con usuarios otra vez, mejorar … repitiendo hasta que esté bien. Aquí es donde el desarrollo ágil y el diseño centrado en el usuario pueden trabajar juntos con brillantez.

El desarrollo ágil realmente trata de averiduar (o suponer más bien dicho) qué se necesita para cambiar las cosas,  y eso es algo bueno cuando proviene de un proceso de refinamiento.

Descubriendo requisitos para formar una estrategia

Diseño Centrado en el Usuario (DCU) no se trata de responder a los requerimientos, sino que también incluye la definición de requisitos. Debemos presumir poco acerca cuál debería ser la solución a un problema específico y poco acerca de lo que el problema en realidad es, poque las presunciones nos cierran a nuevas posibilidades.

Es preferible, para hacer alguna investigación de diseño, crear un punto de vista y luego formar una hipótesis sobre lo que podríamos construir.

En cuanto a esto, nos cruzamos con reino de los product managers, productores, administradores de programas, analistas de negocio y similares, encontrando poco espacio y harta resistencia alrededor. Frente a la reticencia para definir las aburridas y viejas necesidades del negocio (diferentes a las necesidades del cliente), estas personas limitan nuestro trabajo DCU a las pruebas de usabilidad en diseños que cumplan los requisitos que ellos establecen.

Ellos prefieren que nos dediquemos sólo a ayudar con el desarrollo, si pudiéramos hacerlo más rápido con una metodología de desarrollo ágil… sería fantástico.

¿Es siempre conveniente hacer una amplia investigación antes de comenzar el diseño? Eso es una buena pregunta y una que Jared Madurez puede ayudar a responder. A veces podemos obtener información que no se encuentra fácilmente frente a nuestros ojos, por eso es importante que conozcamos las necesidades de los usuarios, tenemos que darnos el lujo de hacerlo. La investigación es un componente esencial para poner nuestros pies en el lugar correcto.

Después de investigar lo que los usuarios y la empresa requieren, podemos aplicar la estrategia de Experiencia de Usuario de Jasse James Garrett (puedes verlo con más detalle en su libro The Elements os User Experience)  sobre esto se debiera basar todo lo que vamos a hacer durante el proyecto. Al aplicarlo no debería haber ningún error extraordinariamente grande.

Lamentablemente, las metodologías de desarrollo ágil no da cuenta de esto más allá de la fase de planificación (la iteración cero), que bien puede definir una estrategia, pero ¿puede de esta forma definirse una estrategia correcta?.

Sin duda, a través de una cuidadosa consideración de tres cosas:

1. Con una empática investigación cualitativa que descubra y revele el contexto del usuario, sus necesidades, metas y objetivos.

Cooper sugiere que el cliente no sabe lo que quiere y defiende el papel de diseñador de interacción como planificador de necesidades. Esto evitaría la mala construcción de los requisitos, pero el tiempo para hacer esto debe entrar en el ciclo de desarrollo en alguna parte. Se trata de hablar con los usuarios (preferentemente en persona) en su medio ambiente para crear modelos y personajes y casos de la experiencia de usuario.

2. Es recomendable hacer un análisis detallado qué sitios parecidos existen en Internet, puede ser en términos de productos, características y tecnología (no necesariamente hacer frente a una situación similar a la nuestra, sino que tome ciertas características con las que nuestro proyecto se vea identificado).

3. Una articulación clara del problema del negocio, los objetivos, las medidas de éxito y limitaciones. Lo que discute la gente de negocios debe ser informado y considerado en la etapa de la estrategia.

Desarrollo del concepto

Si logramos construir algo útil e intuitivamente razonable sin investigación o estrategia, ¿tuvimos éxito? La mayoría de los reproductores de MP3 se ajustan a esto, pero ninguno salió como el iPod de Apple.

Dejando a un lado usabilidad de una interfaz, el iPod tiene un concepto de servicio detrás, que incluye la digitalización, la reposición y la gestión de tu colección entera de música con iTunes. Esto fue parte del concepto del iPod desde el principio y en combinación a un buen plan de marketing y diseño, y aún continúa eclipsando a la competencia después de siete años.

Si no se aplica explícitamente este aspecto fuera de nuestra metodología ágil, es posible que ese valioso tiempo para pensar se pierda.

Lo mejor de ambos mundos

En la metodología de diseño centrado en el usuario puede ser que la documentación sea  demasiado pesada y compleja, pero las metodologías de desarrollo ágil necesitan ayuda con los requisitos de la definición y desarrollo del concepto.

¿Cómo pueden los principios de ambas metodologías trabajar juntas?

Primero entendamos lo que funciona bien con la metodología de desarrollo ágil y no tan bien con el diseño centrado en el usuario.

En este sentido, el trabajo del diseño centrado en el usuario puede producir documentación que no se lee, describiendo interfaces específicas de forma aislada que quizás no serán viables ni ser codificadas en el tiempo asignado.

Así, si se requiere hacer un diseño detallado es mejor hacerlo en conjunto con el equipo de desarrollo, de manera  que las interfaces resultantes puedan ser ajustadas a medida que se trabaja.

Una visión compartida de los fundamentos de la interacción

En el desarrollo de un buen software, un modelo de interacción conceptual que ha sido pensado de antemano destaca por la forma en el usuario navega por el sistema, como realiza tareas y utiliza las herramientas en términos genéricos.

Después de que mapa ha sido esbozado, reforzando la investigación y la conceptualización antes de la actividad de desarrollo, es posible garantizar la coherencia y la cohesión de cada componente cuando posteriormente se codifica por separado.

En muchos casos, el conceptualización necesitará iteraciones para dar cabida a las diferentes experiencias y tendremos, a lo menos, alguna indicación (o modificación) a grandes rasgos.

Entonces, en medio de iteraciones del desarrollo ágil, arreglando los detalles al lado del equipo de desarrolladores, se requiere un nivel de experticia y experiencia de parte del diseñador, porque lo que diseñamos se construirá antes de que tengamos tiempo de arrepentirnos.

El riesgo que se presenta en la interfaz son las nuevas y significativas mejoras de lo que ya se ha hecho. Esto es preferible abordarlo como una actividad única en un sprint antes de desarrollarlo (no trate de producir código).

Esto evita la presión de entregar algo antes de que esté en óptmo estado, hacer un ejercicio de reflexión y testear con usuarios le asegura que no estamos perdiendo el tiempo y esfuerzo.

A veces la mayor parte del producto se hace de esta manera y eso está bien siempre y cuando los desarrolladores y diseñadores trabajen juntos y exista una relación de comunicación diaria.

Las primeras iteraciones de desarrollo son muy importantes para los desarrolladores para sentar las bases de arquitectura basada en la visión. Los diseñadores deberían utilizar este tiempo para adelantar el trabajo en las interfaces más complicadas y de alta prioridad.

Lo más importante para el éxito: el área de negocios tiene que aceptar que algunas cosas no se verán bien ni estarán perfectas en un principio. Mientras que el compromiso del equipo, antes de la liberación del producto, es no dejarse arrastrar en la tentación de lanzar algo que no está desarrollado de manera óptima o como se acordó en un principio.

Conclusión

En resumen, las actitudes dogmáticas acerca de cada uno de estos enfoques deben ser evitados si necesita combinar ambas metodologías.

Recuerde, el desarrollo ágil no exige una forma de definir conceptos y no es una dirección de diseño global, pero es una gran oportunidad para ejecutar una investigación de diseño sólido y bien establecido. El diseño centrado en el usuario debe ser lo suficientemente flexible como para responder a la realidad cuando el equipo de desarrollo encuentra problemas.

Los documentos sólo se necesitan para hacer llegar el mensaje, porque la colaboración interdisciplinaria y la comunicación cara a cara son vitales.

Trabajando en un sprint por delante del equipo de desarrollo es muy útil para dar al  equipo de diseño tiempo suficiente para probar (adelantarse a los hechos).

Si estas reglas  son consideradas, los dos enfoques pueden trabajar muy bien juntos.

Relacionados:

• Llevando el diseño centrado en el usuario al desarrollo ágil I.
• Llevando el diseño centrado en el usuario al desarrollo ágil II.

“…
El campo minado

En sí mismas, las metodologías de desarrollo ágil hacen un buen trabajo en cuanto a su flexibilidad frente a los cambios. Pero es necesario preguntarse si ésta fue diseñada para tratar un gran síntoma de las organizaciones: la empresa no sabe lo que quiere. Aunque el equipo de desarrollo ágil podría hacer frente de mejor forma a esto, en otras ocasiones no se resuelve el problema y en la mayoría de los casos crea otros nuevos.

Mina 1: El papel del diseño es poco claro

Las empresas contratan a los desarrolladores para crear programas, sitios, aplicaciones o sistemas, algunos de los desarrolladores pueden tener habilidades de diseño, pero eso no es un escenario muy común. Muchos desarrolladores también han tenido malas experiencias con los diseñadores, por varias razones (no son apropiados, no conocen el negocio, etc).

Ha tomado tiempo lograr enfrentar el diseño (como profesión) y el diseño de sistemas complejos, pero todavía hay un déficit de conocimientos en este campo. Más complejo se torma el escenario cuando uno de los principios del desarrollo ágil dice que “la gente de negocios y los desarrolladores deben trabajar juntos diariamente a lo largo del proyecto”. Entonces ¿dónde encaja acá el diseñador?.

Mina 2: El proceso de recopilación de requisitos no se define

El desarrollo ágil acoge las actividades de diseño desde la perspectiva de un desarrollador, tiende a recibir las especificaciones desde el punto de vista del requirente (empresa o cliente que se supone que todo lo saben) y da por sentado que éstos son apropiados.

Según Ken Schwaber, SCRUM tiene la intención de ser una metodología de gestión integral y deja espacio para otras actividades (para que la programación se produzca en el marco de los ciclos iterativos).

Pero cuando las organizaciones adoptan SCRUM, con frecuencia desechan las buenas partes del desarrollo en cascada como la investigación y la formación de un plan de alto nivel para el diseño general, arrojando por la borda la documentación.

Como el Manifiesto del Desarrollo Ágil dice que el software es más importante que la documentación completa, muchos apelan a esto y no quieren hacer ningún tipo de documentación, algo que puede ser muy valioso para presentar un esbozo de la visión institucional, aunque sea en un sentido rudimentario.

Mina 3: La presión para cortar las esquinas

Las implementaciones de desarrollo ágil ubican las actividades de diseño dentro de las mismas iteraciones que el desarrollado, para garantizar o asegurar que el diseño se realice y se desarolle al momento de hacer el código. Esto también impone una enorme presión sobre el equipo de experiencia de usuario, el de “alimentar la máquina de desarrollo” en el tiempo suficiente para que se pueda poner en práctica su visión.

Esto puede llevar (y de hecho así ocurre) a diseñar impulsivamente. ¿Qué hay de malo en eso? Nada si el trabajo está basado en los principios del diseño centrado en el usuario. Desde esta perspectica se sugiere que se debe probar las ideas con los usuarios finales antes de comprometerse a desarrollar el código.

Sin duda, nos permite ahorrar mucho tiempo y recursos, y levanta una importante duda ¿cómo sabemos si la maqueta funciona de la misma forma como si ya estuviera programada, en un contexto diferente, sin haber probado antes con el usuario? ¿Cómo podemos innovar copiando lo que ya existe?

Antes de que Google reinventara las búsquedas en Internet, otros motores de búsqueda suponían que le correspondía al usuario aprender a buscar de manera adecuada.

La mayoría de los resultados de búsqueda eran pobres, entonces Google llegó y se dio cuenta de lo que ahora es evidente: La gente sólo quiere encontrar lo que necesita, no quiere aprender a usar un motor de búsqueda.

No estoy sugiriendo que los otros motores de búsqueda no podría haber hecho lo que Google hizo antes, sólo estoy señalando con el dedo la pérdida de oportunidad por no considerar las necesidades de los usuarios.

Curiosamente, Google no es conocido por sus diseñadores. Es principalmente una casa de desarrollo, pero muchos de los desarrolladores claramente tienen cierta sensibilidad con la experiencia de usuario, particularmente cuando se trara del diseño centrado en el usuario.

No hay nada de malo en usar la matodología de desarrollo ágil para producir resultados rápidamente, si tiene la intención de hacer pruebas de usabilidad con anterioridad. Sin embargo, no hay que dejarse engañar pensando que esto podría ahorrar mucho tiempo, dado que ante el desconocimiento y el apuro los resultados pueden ser más costosos.

Mina 4: La tentación de llamarlo “suficientemente bueno”

Invariablemente, cuando se ha terminado el código a finales de cada ciclo, se corre el riesgo de liberarlo aunque no sea lo suficientemente bueno. A veces, eso involucra hacer lo que sea para terminar el ciclo y comenzar con otro, pero en definitiva puede que no sea lo mejor para el usuario.

¿Hay que gastar tiempo en la próxima iteración u ocupar tiempo en arreglar sobre la que se está trabajando? Demasiado a menudo, el re-proceso va en favor de comenzar el nuevo desarollo y resulta un producto con ciertas características que probablemente no van a satisfacer a los usuarios.

Mina 5: Insuficiente tiempo para explorar el riesgo

La iteración “cero” (es decir, una planificación y diseño de la iteración anterior a la iteración del primer desarrollo) se puede utilizar para hacer esto y otras actividades de planificación.

Sin embargo, dependiendo de cuánto tiempo se demora esta iteración, el nivel de rigor aplicado a la exploración puede ser insuficiente.

Un argumento utilizado por algunos profesionales de metodología de desarrollo ágil es que hacer un ejemplo práctico (ir entregando productos programados) es la mejor manera de validar si es adecuado a las necesidades del cliente.

El “suck it and see” omite la conceptualización, las actividades donde se dedica tiempo a esbozar soluciones diferentes a un nivel alto y validarlos con los usuarios antes de excavar en el diseño detallado o hacer el código. Con el “Suck it and see” habría solamente que construir, lanzar y ver si se tuvo suerte y cumplió con satisfacer a los usuarios. De esta forma, se pierde tiempo de producción en desarmar o reconstruir.

El argumento contrario es que si se tomó el tiempo para construir, habría que considerar el tiempo para investigar y diseñar antes de hacer una línea de código.

Tiene que haber cierto nivel de diseño independientemente de la metodología se utiliza, y esto suma días a la línea de tiempo.

Mina 6: Marca daños

Digamos que el diseño y la investigación toman la misma cantidad de tiempo que el desarrollo. En el peor de los casos, se pierde por completo la marca o la visión por no hacer una investigación y diseño de la solución, en ese caso se debe comenzar todo de nuevo. Entonces a final de cuentas se gasta el mismo tiempo (teóricamente), pero en caso de comenzar otra vez, sin definiciones de diseño, no hay ninguna garantía de que resulte.

La razón de éxito de muchas empresas es producir productos de forma consistente y servicios adecuados. Por el contrario, la creación de un producto o servicio defectuoso afecta negativamente la marca y la percepción de los usuarios. Se requiere mucho más tiempo para reparar los daños a la marca que hacerlos.

Continuará…

Post relacionados:

• Llevando el Diseño Centrado en el Usuario al desarrollo ágil I

Hace unos meses apareció en mis feeds un artículo escrito por Anthony Colfelt llamado Bringing User Centered Design to the Agile Environment que expone aspectos negativos y positivos acerca de integrar el diseño centrado en el usuario al desarrollo ágil, particularmente en Scrum.

Escribí y traduje este post en 3 partes, el cuarto post lo dejaré para mis reflexiones personales. Acá vamos:

“En cuando tuve la oportunidad de obtener un trabajo post burbuja .com lo tomé. Gocé del lujo de hacer las cosas exactamente como pensaba que era correcto y por un tiempo fue de verdad fantástico.

Formé un equipo con un investigador de usuarios, un arquitecto de la información, diseñadores visuales y de interacción, e incluso establecimos un laboratorio de usabilidad donde tuvimos testeos con usuarios regularmente.

Desafortunadamente, el entusiasmo que tenía por mi nuevo trabajo disminuyó después de seis meses cuando un ejecutivo fue nombrado como Jefe de Desarrollo de Productos, quien nos aseguró que conocía Scrum mejor que nadie.

Como Director Creativo le cedí autoridad para desarrollar el producto como él estimara conveniente.

He trabajado con Scrum antes, entrenando con Ken Schwaber (autor y co-fundador de la Agil Alliance) y sabía un par de cosas desde la experiencia, sobre cómo lograr integrar con cierto éxito un equipo de diseño a uno Scrum.

Esto siginificó que el equipo de diseño debía trabajar en los sprint (trabajo iterativos de 1 mes) por delante del equipo de desarrollo. Pero el nuevo ejecutivo, insistía en que se debía seguir las instrucciones al pie de la letra, es decir, todas las actividades debían ser incluidas en el mismo sprint, considerando también el diseño.

Vinieron requeririmientos desde la imaginación del jefe de desarrollo de productos, y como consecuencia de la presión del tiempo el diseño fue apresurado y mal concebido, en tanto el desarrollo fue también hecho a la rápida, mal hecho o peor aún, sin terminar.

El final de las reuniones informativas del Sprint consistía en una reprimenda para todo el equipo por parte de los ejecutivos (ya que nadie había entregado lo que habían comprometido por tratar de hacer demasiado, o no habían hecho lo suficiente). Cada Sprint consistía en tratar de arreglar lo malo del Sprint anterior “o tirarlo debajo de la alfombra“, además el desarrollo era inestable sobre un código basura. La moral disminuyó, el producto era malo, el personal empezó a rotar… fue horrible.

Este es un mal ejemplo extremo de Scrum. No estoy en contra de las metododologías de desarrollo ágil aunque me da rabia a veces y siento temor cuando escucho a alguien cantando sus alabanzas, sin tener mucha experiencia.

En los últimos ocho años, he visto metodologías ágiles mal aplicadas con más frecuencia que las bien aplicadas (pero sí, se puede hacer bien también). La idea de este artículo es presentar cómo las prácticas de diseño centrado en el usuario (DCU) pueden mitigar los riesgos inherentes del desarrollo ágil y cómo éstos pueden ser integrados dentro de los enfoques de desarrollo ágil.

¿De dónde proviene el desarrollo ágil?

Fue creado por un grupo de desarrolladores, Agile es un enfoque de desarrollo iterativo que toma pequeños pasos hacia la definición de un producto o servicio. Al final de cada etapa, se construye algo que se puede mostrar al cliente (o al dueño de este producto o servicio), de esta manera, es posible incluir al cliente en oportunidades donde las metodologías en cascada suelen fallar.

El desarrollo ágil va en la línea de trabajar y construir algo a medida que se avanza en las tareas, en lugar de hacerlo  al estilo del desarrollo en cascada (donde se profundiza en la especificación) y donde a veces se descubre mucho después que no es posible construir partes de la especificación por determinadas razones (por ejemplo: un error de cálculo o nuevas necesidades).

El desarrollo ágil se puede considerar como una estrategia de gestión de riesgo. Pero en este contexto, a menudo los desarrolladores toman contacto directo con un cliente que no sabe qué es o qué hace un diseñador de experiencia de usuario, arquitecto de información o diseñador de interfaz.

Sabemos que profesionales de estas disciplinas suelen interpretar lo que los clientes quieren y traducirlo a algún tipo de especificación para los desarrolladores. Sin esta función, el desarrollador es libre para elaborar y construir lo que cree que el cliente quiere.

Debido a que el desarrollo ágil necesita mucho compromiso con el cliente, al final de cada iteración (que puede ser cada semana) se reduce el riesgo de ir demasiado lejos hacia la creación de algo que el cliente no quiere. Como tal, es un mecanismo de defensa para las necesidades cambiantes de un cliente durante el desarrollo.

¿Por qué la gente celebra esto?

Es atractivo ante la posibilidad de un retorno más rápido de la inversión, porque se podrían ver resultados u obtener una versión del software antes. En el corto plazo, esto suele lograrse. En el largo plazo puede lograrse también, aunque sólo cuando el equipo no ha sido víctima de la tentación (se abordará con más detalles después).

El desarrollo ágil también es bueno en la generación de impulso, dado que con las iteraciones se puede tener control sobre la velocidad dado que se está continuamente revisando avances y logros. Es necesario alentar a los desarrolladores a hacer sólo lo necesario para cumplir los requisitos.

Debido a que se hace hincapié en contacto cara a cara por un equipo multidisciplinario, las metodologías de desarrollo ágil, tienden a alentar que profesionales de diversas áreas contribuyan desde sus diferentes perspectivas. Esto es generalmente una influencia positiva en la innovación y la velocidad de resolución de problemas. El equipo está facultado para tomar decisiones en cuanto a cómo jerarquizar sobre los requisitos que deben cumplirse.”

Continuará…

Es posible participar escribiendo breves explicaciones o haciendo algo más lúdico, utilizando imágenes, inforgrafías o videos.

Todos pueden participar, pero sólo los miembros del Information Architecture Institute votan. En los anuncios del grupo pueden ver más información sobre premios y otros datos importantes

Como muestra les dejo el video IAs are like Robin Hood y Explain IA? We’d have to go way back ambos de Matthew Hodgson (puedes revisar su Flickr).

Independientemente de lo que estemos haciendo en web en este momento (trabajando, aprendiendo, probando, mirando, experimentando, entre otras cosas) este libro es un imperdible, no pueden no leerlo.

¿De qué se trata? Es un libro digital que aborda en cuatro capítulos “todos los aspectos de la creación de contenidos digitales; la manera de organizarlos para ser presentados mediante sitios web; la usabilidad que facilita el acceso a ellos y, finalmente, la experiencia que vive el usuario que los visita y utiliza” según las palabras de su autor.

Juan Carlos es periodista y es la máxima autoridad en Chile sobre temas de arquitectura de la información y usabilidad (además de ser un ejemplo personal y profesional para mí). Tiene méritos y experiencia de sobra para concretar (al fin!) este lindo proyecto, pero hay un aspecto muy destacable en él que es el compartir este conocimiento con todos nosotros, por lo que aprovecho este post para darle infinitas gracias por ello.

El libro estará disponible para su descarga el jueves 5 de noviembre dado que ese día es su lanzamiento oficial. Estará en formato pdf y es gratis.

Más información:

• El lanzamiento es la UDP a las 11.30 horas en Vergara 240, Primer Subterráneo (Estudio de TV), Santiago de Chile.
• El 24 de noviembre a las 19.30 habrá una presentación en el Instituto de la Comunicación e Imagen de la Univeridad de Chile (Avenida Capitán Ignacio Carrera Pinto 1045, Ñuñoa, Santiago de Chile).
• Puedes seguir a Tienes 5 Segundos en Twitter en @cincosegundos 
• Puedes hacerte fan de su página en Facebook para conocer novedades o discutir sobre algún tema relacionado.

Este año está orientado a conocer cómo los medios de comunicación chilenos han orientado el desarrollo de la experiencia de usuario en sus rediseños o en la utilización de los contenidos diferenciados, para ello, representantes de algunos medios nos contarán sus experiencias.

Viene a demás el director de experiencia de usuario del New York Times, Alex Wright, quien es uno de los AI más importantes a nivel mundial, ha realizado trabajos interesantísimos desde el diseño de interacción, por lo que estamos muy felices por su visita.  Si no lo conocen, les aconsejo que lean su sitio o lo que ha escrito para Boxes and Arrows.

El evento es gratuito, pero deben inscribirse dado que los cupos son limitados. Se llevará a cabo en TVN y los próximos días publicaremos el programa definitivo con todos los invitados en el sitio de AIChile.

El viernes pasado me llegó este correo electrónico de una empresa llamada Cosmmo.net.

Como ven, el mail alude a que supuestamente me hice una cuenta en el mencionado sitio, ¿lo raro? es que eso jamás ocurrió.

Pero eso no es todo, en el correo aparecen algunos de mis datos (verdaderos), sin embargo, aparece otra información absolutamente falsa.

• En primer lugar no tengo ninguna empresa, no soy propietaria de ninguna compañía ni entidad.
• En segundo lugar, jamás he vivido ni trabajado en esa dirección, no sé si existe, pero por lo menos el teléfono, al parecer, es falso. Llamé decenas de veces y nada, sólo el ruido de ocupado.

Busque en el sitio y leí las Políticas de uso, en ellas se hace explícita la idea que la inscripción es voluntaria:

“Registro, contraseña y seguridad.
Se le asignará un nombre de usuario y una contraseña una vez completado el proceso de inscripción para crear el perfil. El usuario se responsabiliza de mantener la confidencialidad de su contraseña y perfil, y de todas las actividades que se efectúen bajo su contraseña o perfil”

Jamás pasé por un proceso de inscripción, por lo tanto no me cree un perfil, ante esto me queda la duda de cómo voy a ser responable de mantener algo que no hice.

Después de esto pensé que: “o es una broma o los dueños de Cosmmo.net están perdidos porque se atrevieron a registrarme en su sitio sin mi consentimiento”. Entonces busqué en el sitio un número de teléfono, me contestaron luego de 2 horas de intentos.

Al explicarle la situación a la persona que me atendió su respuesta fue: “usted misma vaya y elimine su cuenta”, sin entender que no tenía por qué hacerlo.

Posteriormenteme dijo que lo único que habían hecho era “incluir una base de datos que le había llegado no sé de dónde” en el portal. Por lo tanto, supongo que no fui la única que recibió su usuario y contraseña.
Le pedí lo más amablemente que pude que me borrara del portal, de lo contrario recibiría una demanda. La verdad no sé si es demandable, pero me dio rabia.

Lo más grave del asunto, es que mi trabajo me obliga a no tener relaciones comerciales con ninguna empresa privada, de hecho varias veces me han ofrecido participar en proyectos y he explicado lo mismo que digo ahora en mi blog: no puedo tener participación en empresas privadas en mi actual trabajo, no puedo recibir otro sueldo ni mantener otra actividad comercial con privados (sólo académicos), por eso traté de hacerle ver a esta empresa que es grave lo que hicieron, en primer lugar nadie me pregunto, y en segundo lugar mintieron descaradamente.

Hoy retiraron mis datos del sitio, traté de entrar con ese usuario y contraseña y no pude. Hace un rato entré en el sitio para ver el teléfono, llamar y agradecer, pero oh sorpresa!!! sacaron el teléfono del sitio, dejaron sólo el de sus supuestas oficinas en Norteamérica.

Como soy precavida y pensando que esto le puede pasar a otra persona, el número es +56322110054. Se demoran en atender, pero contestan finalmente.

Creo que es redundante explicar el título, aún así y por si alguien no entendió, esto es una pésima práctica y sólo demuestra que estás personas no son las que más saben en el rubro del diseño y estrategias web.

Hace tiempo quería escribir un post como éste. Hubo algunos acercamientos, pero debo reconocer que el tema de los sueldos y remuneraciones en Chile es un tabú.

Hoy en Twitter se habló bastante del tema, sin embargo, lo que me llamó profundamente la atención no fue el interés por saber cuánto ganaban los funcionarios públicos, sino los constantes “quiero trabajar en el gobierno” o “debería trabajar en el gobierno”.

Fuera de broma, las expresiones suscitadas por los datos entregados por las instituciones públicas, me hacen pensar en la diferencia de sueldos reales entre un profesional de la usabilidad (como yo) en el sistema público y en el sistema privado.

Existe el prejuicio que los sueldos del sistema público son más bajos que en el sistema privado, sin embargo, con la transparentación de las remuneraciones muchos de nosotros nos hemos percatado que probablemente esto no sea tan así. Y considerando que quizás soy un caso atípico, me atrevo a expresar lo que opino de todo esto.

Deben existir empresas privadas (probablemente transnacionales) donde efectivamente un profesional con mis características gane lo mismo o un poco más que yo. Pero muy pocas le dan un valor real a nuestro trabajo, muchas veces por pensar que lo están haciendo bien y otras por ignorancia.

A pesar de ello, ¿por qué mi interés de resaltar este dato o hacer esta comparación? Porque veo claramente cómo excelentes profesionales relacionados a esta disciplina ganan en el sistema privado mucho menos de lo que merecen, de lo que necesitan y de lo que valen. Y en resumen, veo como un mismo profesional con mis habilidades, conocimientos y experiencia gana en el sector privado la mitad de mi sueldo o incluso menos.

Cuando supe de esta ley, debo reconocer que sentí vergüenza de que todo el mundo se enterara de mi remuneración, sin embargo, ahora le veo el valor y el lado positivo, esto podría perfectamente servir como una forma de medir los sueldos para profesionales del sector privado. De comenzar a valorar más, no tanto con palabras y buena onda, porque así no se pagan ni las cuentas, ni los estudios para seguir perfeccionándose.

No creo que el verdadero valor se mida en dinero, pero me imagino la expresión de varios al ver que con su experiencia, estudios, conocimientos, ganan lo mismo o menos que un profesional que no tiene más de 2 años de experiencia y que sólo posee un título universitario.

A pesar de todo lo que pueda desear y lo que pueda meditar, nada de esto vale o sirve si seguimos sumidos en la inseguridad. El precio de mercado de un buen profesional debe valer mucho más de lo que creemos o pensamos.

Como les decía a unos alumnos de diseño la semana pasada: Los principales responsables de que nos miren sin profesionalismo somos nosotros, si no explicitamos el valor real que tenemos nadie lo hará por nosotros.

Han pasado muchas cosas desde que escribí aquí por última vez y estoy muy feliz porque han sido eventos y situaciones tremendamente interesantes.

Ya, comencemos.

Hace rato que sé la diferencia entre las organizaciones que se preocupan de sus usuarios y aquellas que simplemente no les interesa, quienes piensan que gastar en usabilidad es una pérdida de dinero y que no vale la pena.

No quiero hablar éstos los últimos, ya habrá otros post para ellos. Quiero destacar lo positivo y así, como una forma de celebrar este reinicio, es que quiero contarles dos cosas:

• Chilecompra (mi nuevo lugar de trabajo) tendrá laboratorio de usabilidad. No sé si actualmente hay otra experiencia con otros organismos públicos, sin embargo, estoy tremendamente feliz de llevar a cabo esta tarea tan significativa en MercadoPublico.cl (específicamente). Más detalles los daré en el futuro.
• La escuela de periodismo de la Universidad Católica de Valparaíso está potenciando el área digital de su malla, incorporando temas de Arquitectura de la Información y Usabilidad de manera más directa. Aunque me parece que, a diferencia de otras universidades, ha sido un poco tarde, dicen por ahí que más vale tarde que nunca.

Como se ve, en estos momentos estoy experimentando algo bastante peculiar, viviendo y trabajando en una organización que se dio cuenta que era necesario incorporar a los usuarios en sus procesos de diseño, como consecuencia de comprender que la usabilidad no es sólo un cliché que suena bonito, raro y cool.

Estas buenas noticias son el pie para lo que viene, prometo post seguidos como antes, puro conocimiento compartido.