Archive for ‘Methodology’ Category
En The Pipeline to your corporate soul, uno de los artículos que más hondo me caló el pasado año, Alan Cooper hablaba de las similitudes entre el lenguaje corporal y el software, y de cómo muchas compañías contratan a profesionales del diseño de interfaces sólo para realizar cambios estéticos cuando en realidad necesitan cambios más profundos.
Software has become like body language in the way it reveals your inner personality to a patient observer. Your body language always tells the truth, even when you are trying to hide an ugly secret, and it will give you away every time. You simply can’t create likable software if you are a dysfunctional company.
Cuanto más tiempo me dedico a esto, más profundamente creo que los cambios se tienen que introducir primero a nivel de organización, para que estos afloren a la superficie, es decir a la interfaz.
Incluso si eres capaz de entregar un trabajo de diseño y definición de experiencia de usuario excelente, de nada sirve interpretado en manos de una empresa con trabajadores desmotivados o consejos de administración multitudinarios; será raro que la implementación final se asemeje algo proyecto entregado. Por eso cada vez creo menos en el concepto de acuerdo por entregables, y más nuestra integración dentro del equipo del proyecto.
De otra forma nos convertimos en osteópatas de las interfaces, nuestro día a día transcurre corrigiendo los vicios posturales de la empresa, pero si está no adquiere buenos hábitos, estos suelen volver a aparecer pasado un tiempo.
Uno de los aspectos que más se ha criticado en Twitter del reciente rediseño de Gmail y en general de las aplicaciones de Google, es aspecto de los botones, aparte de eliminar las etiquetas y basarse completamente en iconos, su aspecto es completamente plano.
En general el nuevo look & feel tiene un aspecto excesivamente plano y monocromo, con poco contraste y sin apenas pistas visuales que indiquen qué elementos son clicables y cuales no.
Uno de los argumentos principales para el nuevo rediseño es la limpieza y la modernidad. Sí bien es cierto que es mucho más limpio, no obstante es excesivamente diáfano y con falta de focos claros, y el cepillo de la modernidad se ha llevado por delante la affordance de muchos elementos.
Por definición la affordance es la cualidad de un objeto que nos da pistas de cómo se utiliza, en el caso de los botones es su aspecto pulsable, es decir los pequeños matices en el diseño que indican que el botón sobresale de la superficie y que se puede hundir.
No hace falta realizar grandes cambios para dar estas pistas, tan sólo realizando pequeños cambios en el diseño podemos conseguir este efecto.
Tomemos como base el diseño actual:
Sí, es sencillo y elegante, pero ¿qué problemas tiene? Por su aspecto podría ser tanto un botón como una caja de texto. Para hacer más explicita su función, elevemos un poco el diseño para que sobresalga virtualmente de la superficie de la interfaz:
Ahora parece un poco más pulsable, pero podemos hacerlo más evidente añadiendo algunos matices:
Ahora el botón no es tan plano, hay una pequeña elevación en la zona central que nos invita a pulsarlo. Aún así se puede realzar más:
Sin perder del todo la coherencia en colores y el estilo general, mediante cuatro pequeños cambios en el diseño, hemos conseguido que el botón tenga más aspecto de botón. De la misma forma podríamos mejorar el contraste entre mensajes leídos o no leídos y la diferenciación entre grupos de mensajes del nuevo diseño.
En este pequeño ejercicio es posible que hayamos perdido modernidad por el camino, pero si tenemos en cuenta el uso intensivo que hacemos cada día de estas aplicaciones, aspectos como la ergonomía, la accesibilidad y la psicología de la percepción son muy importantes, y al fin y al cabo las modas son siempre pasajeras.
En el diseño de escaleras (sí escaleras convencionales, las que subís y bajáis todos los días en cualquier edificio o en el metro), uno de los principios fundamentales es la pendiente, una relación geométrica que viene definida por la profundidad de los peldaños (llamada huella) y la altura de éstos (llamada contrahuella o tabica).
Todos sabemos subir y bajar escaleras, ese movimiento está implantado en la memoria muscular de nuestras piernas desde nuestra primera infancia y se consolida a partir de los 3 años de edad aproximadamente. Pero en cada escalera realizamos una pequeña adaptación de la cadencia de subida o bajada. Esa cadencia viene definida por la pendiente de la escalera, la cuál ha de ser constante para mantener el ritmo y evitar caídas.
Seguro que muchos de vosotros os habéis dado un traspiés con una escalera mal compensada o un escalón desnivelado por culpa del desgaste. Cuando afrontamos una escalera, digamos que el primer escalón nos da toda la información necesaria a nuestras piernas sobre la cadencia a seguir, si esta cadencia se altera el tropiezo está asegurado.
De la misma forma, en el diseño de formularios, la consistencia en el diseño global (distancia entre campos, tamaño, adecuación a su contenido, alineación de etiquetas…) lo que vendría a ser el equivalente a la “pendiente” de la escalera, determinan la velocidad con la que el usuario introducirá la información.
Cualquier variación o inconsistencia en el diseño de uno de sus peldaños implicará un “tropiezo”, que en el contexto web puede implicar una “caída” o abandono de la página.
Hace cosa de un año aproximadamente, yo me encontraba esperando a una persona en la Plaza Cataluña de Barcelona, era un día entre semana por la tarde.
Mientras mataba el tiempo ojeando un libro, un turista con aspecto “mochilero” y los ojos hundidos en ojeras, me espetó en inglés con un acento totalmente yanqui:
- “Excuse me. Where is la Roamblasss?” (preguntándome por la Ramblas).
- “La tienes ahí mismo”. Le contesté mas o menos (sólo tenía que darse la vuelta para encontrar la calle)
El tipo al parecer recién salía de la estación de tren, y estaba totalmente desorientado.
- “Oh cool. Ah! una cosa más: (mientras me ofrecía amablemente un cigarrillo) ¿Está muy lejos Andorra?”
- “¿Perdón?”
- “Sí, Andorra, montañas, Piranios…” (Pirineos). “Quiero coger el tren mañana por la mañana para ver Andorra”
- “Ah! Quieres hacer senderismo” (por buscarle algo de sentido a la pregunta, el tipo me calló simpático ¿Y quién demonios pregunta por Andorra en el centro de Barcelona?)
- “No, no… quiero visitar Andorra. Hoy Barcelona, mañana Andorra, pasado París, luego Londres… vuelvo dentro de 4 días a Colorado.”
Ahí ya me desmontó completamente.
- “Pero entonces… ¿No vas a conocer nada de la ciudad? ¿Te vas a pasar las vacaciones en los trayectos?”
- “No me importa, tengo 7 días de vacaciones por Europa y quiero estar en el mayor número de lugares posibles.”
Después me despedirle me quedé observándolo mientras desaparecía entre el tumulto de turistas de las “Roamblass”. Otro turista Foursquare.
Personalmente es un tipo de experiencia que no entiendo. Cuando visito un lugar de vacaciones, me gusta establecer un “campamento base” y planificar visitas por la zona, intentando descubrir todos sus rincones. La experiencia Foursquare, me parece totalmente dominada por la ansiedad, estar en todos los lugares pero no estar en ninguno, llevarse un bonito mapamundi con check-ins a la tumba.
Del mismo modo, una práctica bastante extendida en nuestra comunidad es realizar propuestas de diseño basándose en el volumen de pantallas, lo cual me parece una aproximación bastante superficial a los proyectos.
¿A cuánto va la pantalla? No tengo ni puñetera idea, depende de la pantalla… Si hacemos realmente experiencia de usuario, y si se trata de un proyecto complejo en el cuál no se puedan aplicar “de cajón” los patrones de diseño de interacción existentes, y en el que sea necesario la participación de alguien que ayude a definir la experiencia de usuario (no a pintar los wireframes o diseños que tenga pensados con todo lujo de detalles el cliente) soy más partidario de acordar colaboraciones a largo plazo, de un mínimo de 2 a 3 meses.
¿Tanto? Teniendo en cuenta las iteraciones por cada pantalla, variaciones según volumen de información, cambios de estado, especificaciones, documentos funcionales, test, cambios post-implementación… Yo más bien diría, tan poco.
Es por esta razón que el modelo boutique basado en el entregable final creo que carece de sentido si nos dedicamos a los que nos dedicamos.
Con una aportación puntual de un estudio o empresa de UX o diseño, tendrás una bonita estilización de tu proyecto que posiblemente sólo podrás utilizar como inspiración. Mi recomendación, si estás pensando en contratar a un experto en UX, es que lo metas realmente en la cocina de tu proyecto durante una buena temporada, no que sólo haga check-in.
Any building, plumbing, paving, furniture, the clothes you’re wearing… will have a useful life greater than the application or website you’re working on.
Document your work, synthesize and draw conclusions from what you have learned along the process, because it’s the only thing that will help you in the next project.
Este fin de semana me ha venido a la memoria una anécdota que me explicó un compañero de trabajo hace muchos años, a propósito de sus peripecias en un largo viaje en el Transiberiano.
Como muchos sabréis, el ferrocarril transiberiano (o Транссибирская магистраль, Транссиб en ruso) es la red ferroviaria que con 9.288 km atraviesa Rusia de occidente a oriente, enlazando con Mongolia y China. Debido a la dureza del viaje, a lo largo del trayecto cada cierto tiempo se cambian las locomotoras y se comprueban los bogies, la estructura sobre la cual que descansan los vagones y donde se encuentran las ruedas.
El método para verificar que los bogies se hayan en buen estado puede parecer a priori bastante tosco, pero es muy efectivo: unos operarios recorren todos los vagones del tren, golpeando con una barra de acero cada uno de los bogies.
Estos trabajadores tienen el oído tan educado al ruido característico del metal, que pueden detectar cualquier sutil anomalía en la estructura según el sonido que emita, ajustando los componentes del mecanismo para que el “ruido” sea el correcto.
Al parecer, a mi compañero le sacaba de juicio esta rutinaria y ensordecedora ceremonia, ya que los operarios, una vez terminado el recorrido, se reunían con calma y parsimonia en un lateral del convoy para repasar visualmente el trabajo hecho, y los tipos se tomaban su tiempo… disfrutando del momento con una cierta actitud de reconfortante compañerismo por el trabajo bien hecho.
En estos tiempos de fechas de entrega inamovibles, y de prisas por obtener lanzar el proyecto cuanto antes y obtener resultados ¿Recordáis alguno de vosotros la última vez que habéis repasado con calma y mimo alguno de vuestros proyectos? ¿No os habríais ahorrado muchos dolores de cabeza si hubiérais dedicado el tiempo necesario a revisar el trabajo?
Si eres diseñador esta situación te será familiar: un compañero de la oficina se levanta a tomar café y cuando pasa detrás de tu silla se queda parado detrás tuyo mirando a tu monitor. “Oh! perdona que te moleste, pero es que me parece cosa de magia lo que haces.”
Magia (del latín magia, derivado a su vez del griego μαγεία, de igual significado que en español, probablemente del antiguo persa magush, que contiene la raíz magh-: “ser capaz”, “tener poder”; haciendo referencia a la antigua casta sacerdotal persa) es el arte con el que, mediante conocimientos y prácticas se pretende producir resultados contrarios a las leyes naturales conocidas valiéndose de ciertos actos o palabras.
Para los que no trabajan con elementos visuales, la actividad del diseño y todo lo desarrollado con la plástica tiene mucho atractivo, como si se tratase de un don innato inaccesible para algunas personas, las cuales no comprenden los procesos mentales que hay detrás de la práctica del diseño, sólo ven el “truco” final.
Jared Spool lleva años trazando paralelismos entre la magia y el diseño de la experiencia de usuario, seguramente influenciado por su hijo reed, con el cual recientemente realizó una charla en IDEA 2010; The Best is the Enemy of the Good, donde habló de la similitudes entre el aprendizaje de la magia y el diseño de experiencia. En el correspondiente podcast en Johnny Holland comentaba algo así: “Cuando quieres hacer magia el primer truco siempre sale horroroso, y luego cuando crees que sabes algo, te comparas con otros magos y sientes que eres lo peor”.
“What you may not realize, however, is professional magic has a hundred year jump on experience design. That field’s drive for perfection started before the time of Houdini, in the late 1800s. The methods, philosophies, and culture behind their drive has gone through many years of refinement and maturation. There’s a lot that today’s experience designers can learn from how professional magicians approach their craft.”
Si te dedicas a esto sabrás que no naciste aprendiendo a diseñar, quizás a temprana edad alguien te dijo que dibujabas bien (y te lo creíste), y esa motivación te sirvió de acicate para seguir practicando, o quizás tu interés se despertó más tarde, pero tuviste que practicar, copiar a otros, leer mucho para justificar tus decisiones y equivocarte muchas veces hasta llegar a lo que sabes ahora, es más, hoy en día tienes la sensación que aún sabes menos que cuando empezaste y que aún te queda mucho por aprender.
“To say I’m at that fourth level for everything I do would be completely wrong. As the great Robert Heinlein would say, ‘I am only an egg”.
Trabajar con los modelos mentales, alterar la percepción y hacer disfrutar al espectador de la experiencia son trucos del oficio del mago. Las mismas técnicas que los diseñadores utilizan para crear ilusiones en los productos.
Al hacer magia, tienes que separar el modelo mental del espectador del modelo mental del mago. Solo el mago comprende todo lo que pasa a través de su punto de vista (ya sea un juego de espejos, o una cuestión de velocidad con la manos). En este sentido los diseñadores pueden definir modelos mentales que alteran la percepción de los acontecimientos. Por ejemplo, un simple “truco” de diseño (una barra de progreso, ofrecer datos de forma secuencial) puede acelerar la percepción de velocidad de respuesta del sistema.
Un mago también ha de ser un gran contador de historias, ha del dominar el arte de la narración, controlar el clímax durante el truco, al igual que los diseñadores de experiencia de usuario hacen con una aplicación (ese clímax del carrito de la compra).
La magia está de moda últimamente, quizá por el exceso de “realidad” que nos rodea. El otro día sin ir más lejos unos niños me espetaron por la calle “¡Mira, Harry Potter de mayor!”. Qué más quisiera yo, tan sólo se hacer un par de trucos…
In 1971, Jerry Weinberg in his book The Psychology of Computer Programming introduced the term “Egoless programming”, using this concept to describe the mindset that programmers should have in a peer review environment. Basically the idea is to multiply the number of eyes looking for logic problems, resulting in shorter project completion times and lower defects in live systems. To accept this methodology, developers had to set their egos aside.
In usability teams, or if you are a freelance working temporary inside a company, this methodology and mindset is a must, mainly on the prototyping phase, where biggest decisions are taken.
Design community has been traditionally an ego factory, so some commandments from the egoless programing could be easily translated and applied to the design practice in a collaborative environment, to keep our egos under control:
- Understand and accept that you will make mistakes. The point is to find problems on the design early, before you waste time with high-res mockups or some user will have problems on the live project.
- You are not your design. Remember that the entire point of a review is to find problems, and problems will be found. Don’t take it personally when one is uncovered.
- Alike critique design instead of people. As much as possible, make all of your comments positive and oriented to improving the design.
- No matter how much “karate” you know, someone else will always know more. Such an individual can teach you some new moves if you ask. Seek and accept input from others, especially when you think it’s not needed.
- The only constant in the world is change. Be open to it and accept it with a smile. Look at each change to your requirements as a new challenge (e.g. new features, new devices, new scenarios…).
- The only true authority stems from knowledge, not from position. Knowledge engenders authority, and authority engenders respect, so if you want respect in an egoless environment, cultivate knowledge. Design solutions use to be more powerful by the argument that by the solution itself.
- Fight for what you believe, but gracefully accept defeat. Sometimes your ideas will be discarded, maybe due technological restrictions, end users characteristics or simply by industry trends. That will not be defeats, for sure, accept this fact as a natural part of the iteration process.