Daniel Torres Burriel (conferencia usabilidad)
Comienza hablándonos sobre su perfil profesional (freelance, consultor de usabilidad, diseñador de interacción, blogger, etc). Me ha gustado eso de que con el blog ha adquirido gran parte de lo que sabe, por eso le gusta definirse también como blogger.
Le apasione su trabajo y nos cuenta que esto es algo fundamental (me siento reflejado jejeje).
Sobre los diferentes temas abarcados nos comenta que principalmente hablamos de diseño. Y en este momento hacemos un recorrido por la Wikipedia, RAE y WordReference para aproximarnos al significado de este término.
Como resultado tenemos una serie de palabras: proceso, búsqueda de una solución, creatividad, técnica, etc. Ahora bien, ¿cómo podemos afrontar todo esto?. La respuesta es clara: mediante una metodología.
Y en este punto he recordado un libro que leí hace muchos años sobre ingeniería del software (como han cambiado las cosas desde entonces). Bueno, la cuestión es que para la web podemos aplicar una metodología clásica, como la que se empleaba para el software de escritorio (a grandes rasgos).
Hasta aquí todos hemos llegado casi «sin problemas» (me incluyo) pero ahora viene lo mejor.
Daniel nos propone que una vez tengamos la experiencia aportada de la metodología podemos empezar a romper los procesos.
Esto es algo que ya comentaba en su día Alberto Knapp.
Imagino en las palabras de Dani, que en vez de seguir un proceso basado en la sincronía en el que a veces la consecución de objetivos se vuelve unidireccional. Es mejor realizar un proceso asíncrono y bajo una consecución de objetivos bidireccional.
Madre mía releyendo lo que acabo de escribir me están dando mareos 🙁
La idea que se persigue bajo las claves de metodología, proceso y producto es que el resultado final prime por encima del proceso y no al revés.
Bueno, lo importante de toda esta «paranoia» se resume en: iterar.
Prototipar (probar) e Iterar (feedback) interpretando el producto final como el propio proceso metodológico. En este sentido se le da máxima importancia al producto final y no tanto al proceso que se lleva a cabo.
Pero… ¿y si falla alguna de las iteraciones?.
Por ejemplo supongamos que entregamos un wireframe al cliente. Este a pesar de haber recibido una explicación breve de lo que se trata, ve el wireframe y simplemente nos responde diciendo que no le gusta nada el diseño.
En este punto debemos prestar atención a los obejetivos.
En el caso concreto del wireframe no basta con una simple explicación al cliente, hay que describir ese wireframe, presentarlo y explicar su conceptualidad.
Tanto el wireframe, diseño, desarrollo y cualquier entregable tiene que perseguir el cumplimiento de unos objetivos concretos.
Y lo que es aún más importante, todo cliente tiene una serie de objetivos. Puede que nosotros no los conozcamos o que el cliente no los sepa comunicar, pero esos objetivos están ahí.
De hecho todo tiene objetivos, el propio proyecto, los entregables, el cliente, el equipo, la compañía.
En fin, me quedo con descubrir objetivos, tenerlos muy claros, acometerlos, e iterar mirando siempre al producto final y no dejándose manipular por el proceso.
