Metodología en el blog

100 años de diagramas de flujo

24 Ene, 2016, por Sergio.

Como diseñadores de interacción, gran parte de nuestro trabajo es documentar de forma gráfica aspectos conceptuales como procesos y funciones, descripciones de modelos que pueden afectar tanto al software o servicio que estemos diseñando. Uno de los modelos más utilizados, a la hora de representar algoritmos o procesos, son los diagramas de flujo: un artefacto que describe de forma visual y secuencial las instrucciones de un proceso.

Su historia se remonta a principios del siglo XX, más o menos entre 1908 y 1924, cuando Frank y Lillian Gilbreth estudiaron de forma sistemática los movimientos que realizaban los trabajadores con el objetivo de mejorar sus tareas. Documentaron este estudio, mediante películas y modelos en 3D de los movimientos.

Para proyectar gráficamente esta investigación sistemática, crearon un alfabeto visual denominado “Therbligs” (Gilbreth leído del revés), dando nombre a cada una de las acciones involucradas en una tarea.

Therbligs

Mediante la diagramación de therbligs de forma secuencial, podían identificar aquellas aquellas tareas que eran innecesarias o ineficientes, eliminando incluso fracciones de segundo en tiempo perdido, creando así los primeros gráficos de procesos.

Frank Gilbreth presentó en 1921 el primer diagrama de flujo a los miembros de la ASME. En su ponencia «Process Charts – First Steps in Finding the One Best Way«, resultado de la investigación conjunta con su mujer, ya enfatiza el propósito sintético e iterativo del artefacto:

The Process Chart is a device for visualising a process as a means of improving it. Every detail of a process is more or less affected by every other detail; therefore the entire process must be presented in such form that it can be visualised all at once before any changes are made in any of its subdivisions. In any subdivision of the process under examination, any changes made without due consideration of all the decisions and all the motions that precede and follow that subdivision will often be found unsuited to the ultimate plan of operation.

La intención de los Gilbreth era representar de una forma gráfica, abstracta y sintética, las condiciones actuales de un proceso, con el objetivo de optimizarlo para hacerlo más rentable y eficiente. Diagramando un proceso es más fácil de detectar un error y posibles incoherencias, ya que se tiene una visión general de todo el sistema.

Diagrama de flujo para cargar una granada, creado por los Gilbreth.

Pronto llegaron a la conclusión de que también era una forma eficaz de presentar una idea desde el punto de vista del negocio o servicio, ya que se trata de una visualización muy estructurada.

A principios de los años 30, Allan H. Mogensen, un ingeniero industrial que había estudiado los métodos de los Gilbreth, después de realizar trabajos de consultoría en empresas como Kodak, se unió a la Lillian Gilbreth y asociados comenzando a formar a gente de negocios en los métodos de simplificación del trabajo a través del modelado de procesos.

El uso de diagramas de flujo, era una buena herramienta para mediar entre los diferentes departamentos y actores implicados, ayudando a la solución de problemas de comunicación y limando posibles discrepancias. También permitía identificar patrones y similitudes entre procesos, haciendo posible un uso más eficiente de las tareas y facilitando la transferencia de habilidades.

Mogensen formó a muchas personas en las “Work Simplification Conferences”, un programa intensivo de seis semanas que tenía lugar en Lake Placid (New York) y que desde 1937 influyó durante casi 50 años a profesionales como Art Spinanger y Ben S. Grahan, que mediante su programa “Métodos Deliberados de Cambio”, contribuyeron a ahorrar miles de millones de dólares en empresas como Procter & Gamble. Grahan contribuyó además a llevar más lejos el diagrama original que se presentaba en las conferencias de Mogensen, expandiéndolo a múltiples flujos de información.

Mogensen y Grahan

Pocos años más tarde, en pleno fervor del Scientific Management, en 1947 la ASME adoptó un conjunto de 5 símbolos, derivados del trabajo original de los Gilbreth, como el estándar para los diagramas de proceso. El mismo año Herman Goldstine y John von Neumann crearon el actual alfabeto visual de los diagramas de flujo en ingeniería informática, que corresponde a las funciones o instrucciones básicas de una computadora, facilitando así la traducción posterior en un lenguaje de programación.

Símbolos de diagramas de flujo en ingeniería informática.

  • Terminación (rectángulo ovalado), donde empieza o termina el diagrama.
  • Proceso (rectángulo), muestra los cálculos realizados.
  • Decisión (rombo), indica una situación de verdadero o falso.
  • Entrada / salida, indica leer y escribir funciones.

En diseño de interacción se suelen utilizar estos últimos, en una versión más o menos sofisticada según el contexto, y de una forma más flexible combinándolos con otros elementos gráficos.

Sorprende que pese a ser un artefacto utilizado en multitud de disciplinas y metodologías de innovación, se trata de una herramienta con más 100 años de historia diagramada.

Bibliografia:

 

Visiones sesgadas de la Experiencia de Usuario

15 Abr, 2013, por Sergio.

Se dice que el trabajo del profesional de la Experiencia de Usuario (o UX) es explicar qué es la Experiencia de Usuario. Aunque pueda parecer a broma, no hay nada más lejos de la realidad. Detrás de un concepto tan vago como la definición del Arte: la creación y de definición de experiencias a través de la tecnología (en su más amplia acepción), se engloba una amalgama de profesionales con menos cosas en común de las que desearían como colectivo y con discursos a veces completamente opuestos.

El término UX fue acuñado por Don Norman a mediados de los 90’s, cuando era vicepresidente del Grupo de Tecnología Avanzada de Apple, pero tiene sus raíces en la ergonomía (o factores humanos). La experiencia de usuario abarca todos los aspectos de la interacción del usuario con la empresa, sus servicios y/o sus productos.

Pero los productos y servicios tecnológicos son cada vez más complejos, y requieren de una aproximación holística para llevarlos a buen puerto, además de ser evolutivos y flexibles. Se trata un concepto que engloba tantas disciplinas, técnicas y metodologías, que autodenominarse “experto en UX” es casi proclamarse una deidad.

Malentendidos con las disciplinas implicadas

Dan Saffer diseñó para su libro Designing for Interactions, un diagrama de Venn recientemente rediseñado por Thomas Gläser, que intenta hacer una fotografía panorámica con todas las disciplinas que interactúan en la UX.

Las disciplinas de la Experiencia de Usuario (Dan Saffer / Thomas Gläser)

A pesar de ello, hay muchas personas que, aún dedicándose profesionalmente a una de estas parcelas, siguen confundiendo el bosque de la UX con un sólo árbol. Veamos algunas de las facetas que más se prestan a confusión:

El diseño de interfaces

Es muy habitual confundir “Experiencia de Usuario” con el diseño de interfaces, sin embargo diseñar pantallas no es lo mismo que definir sistemas. Tradicionalmente la palabra “diseño” ha sido siempre confundida con “maquillaje”, como el último barniz que embellece el producto, pero las decisiones del diseño tienen su raíz en la estructura.

La estética es un aspecto importante y con un gran impacto en la experiencia final, pero sólo si entendemos el diseño como “proceso”, como estrategia, no como decoración, podremos aportar nuestro granito de arena a la UX.

Además, teniendo en cuenta que la interacción persona-máquina también puede abordarse desde otros sentidos del hombre (por ejemplo mediante interfaces gestuales o auditivas), el componente visual no ha de ser un factor decisivo de la UX.

La última tecnología

En muchas ocasiones los departamentos de I+D se dedican a desarrollar tecnologías y luego buscan una aplicación práctica para las mismas, muchas tecnologías se imponen simplemente porque son nuevas, sin dar apenas tiempo a los usuarios a que se familiaricen con la anterior.

La amortización de una nueva tecnología puede implicar a veces sobre el usuario, la impostura de necesidades que antes no existían. También la voluntad de adoptar rápidamente una tecnología emergente, simplemente porque está de moda (véase la actual burbuja de aplicaciones para móviles) se antepone a la lógica de encontrar la mejor tecnología para resolver un problema de la forma más sencilla para el usuario, o aportar mayor valor.

La usabilidad

10 años atrás, la usabilidad era un concepto muy de moda en internet, muchos de los que nos dedicamos al diseño de interacción aún lo utilizamos como punta de lanza en cualquier proyecto. Sin embargo, hay muchos sistemas en los cuales la eficiencia y la efectividad no son factores determinantes en la UX: la curva de aprendizaje, el componente visceral y las respuestas emocionales son muy importantes en algunos productos y servicios (videojuegos, ocio, productos aspiracionales…). Si bien es cierto que cualquier profesional de la UX que se precie, ha de tener interiorizados los principios básicos de usabilidad y ergonomía, para que siempre estén presentes, en menor o mayor medida, equilibrándose con otros aspectos.

El usuario

El usuario es el foco de la UX, pero no todo ha de girar alrededor del usuario. Hay otros aspectos como la viabilidad y la factibilidad del proyecto que condicionan muchísimas decisiones.

Las 3 patas de una start up: Negocio, UX y tecnología (Des Traynor)

Aunque hay muchos proyectos cuyo objetivo de éxito no es el económico, eso no implica que no deban regirse por las leyes de la viabilidad y del mercado. ¿Cómo se financiará el proyecto? ¿Cómo se conseguirán usuarios? ¿Cuáles serán los objetivos y cómo se medirá su éxito? También tener en cuenta condicionantes tecnológicos como las plataformas utilizadas, la escalabilidad y la seguridad del sistema. No es lo mismo realizar un proyecto para una entidad financiera que para el público infantil, en ambos los aspectos de seguridad y confidencialidad son claves pero se rigen por leyes muy distintas.

Otro aspecto que se ignora muchas veces son las personas implicadas en el proyecto, los propios miembros del equipo también son usuarios, cuya felicidad y eficiencia condiciona mucho el éxito del proyecto.

Disputas entre metodologías, prácticas y procesos

El sector ha madurado lo suficiente como para que los profesionales se especialicen en muchos contextos y ámbitos, lo cual también ha derivado en diversos enfoques metodológicos que a menudo entran en conflicto. Veamos algunas de las polémicas más recientes:

Diseño centrado en la actividad vs. diseño centrado en el usuario

El Diseño Centrado en la Actividad se trata de planteamiento de alto nivel que pone su foco de atención en las tareas y metas en lugar de focalizarse en el usuario como ente individual, dando más importancia a lo que la gente hace, o a lo que como profesionales pretendemos que sean capaces de hacer. Tiene su origen en la Teoría de la Actividad, uno de los principales enfoques psicológicos de la antigua URSS, siendo ampliamente utilizada en psicología, educación, formación profesional, la ergonomía y la psicología del trabajo. El paradigma permaneció prácticamente desconocido fuera de la Unión Soviética hasta mediados de 80s, cuando fue recogido por investigadores escandinavos. Esta perspectiva puede ser muy atractiva en situaciones en las que la base de usuarios es muy diversa y los objetivos múltiples, pero las actividades principales son menos numerosas y más fáciles de definir.

Uno de los puntos fuertes de la Teoría de la Actividad es que cierra la brecha entre el sujeto individual y la realidad social, dirigiendo su atención a la psicología del trabajo y del aprendizaje.

Mike Long, en su polémico artículo Stop Designing for “Users”, promueve la idea de que debemos tratar de ver «la fotografía panorámica» de un sistema y la forma en que las personas interactúan con él, defendiendo que tal vez sea mejor buscar actividades en común y diseñar para fortalecerlas, en lugar de acercarse demasiado y enfocar nuestros esfuerzos de diseño en la satisfacción de las necesidades de los individuos.

Los defensores de esta metodología advierten sobre los peligros de “escuchar demasiado a los usuarios”: aunque la filosofía básica del Diseño Centrado en el Usuario es escucharlos (teniendo muy en cuenta sus quejas y críticas), acceder a sus peticiones pueden dar lugar a diseños demasiado complejos. También es cierto que las personas nos adaptamos a la tecnología y que la propia mejora de la herramienta facilita nuestro trabajo.

Los usuarios nos darán pistas, pero nunca soluciones de diseño. El diseño para todos no ha de ser diseñado por todos, sino por un profesional con autoridad que escuche a los usuarios y que traduzca sus inputs en requerimientos de diseño. Lo cual nos lleva a la siguiente polémica.

El genio solitario vs. el diseño del comité

La metodología tradicional del Diseño Centrado en el Usuario enfatiza la importancia de la observación de las personas utilizando la interfaz, la investigación de usuarios, los test y la opinión de todos los actores implicados en el proyecto. Pero este enfoque tiene muchos detractores que creen que esta metodología tiene tendencia a crear “diseños por comité”, que si bien, aunque puedan resultados satisfactorios, no está orientado a la creación de soluciones sobresalientes o innovadoras.

En contraste, el enfoque tradicional del diseño, sigue defendiendo la figura del director de orquesta. La creación de soluciones dirigidas por el diseñador experto que controla todas las decisiones del proyecto y con una visión clara, global y consistente.

Aunque a priori, la aproximación del director de arte pueda parecer la que ofrece mejores soluciones, es en realidad la excepción que cumple la regla. Los genios no abundan y el talento es una capacidad humana difícil de transmitir en una organización muy grande.

Luego está el riesgo al fracaso, por ejemplo Jeff Hawkins antes de crear la Palm Pilot, tanteó con otras tentativas de PDAs (GRiDPadSize, Zoomer) que no fueron comercialmente viables. Por lo tanto muchas organizaciones, defiende la metodología tradicional del Diseño Centrado en el Usuario, simplemente por aumentar las posibilidades de éxito.

Apple vs. Google (Peter Arkle)

Lean UX vs. Agile UX

Lean y Agile son dos palabras muy de moda en el sector, en realidad simplemente se trata de darle más importancia dos aspectos fundamentales en la UX: el qué y el cómo.

En el modelo tradicional de UX, la investigación es algo que se hace antes de empezar a crear el producto, para saber qué es lo que vamos a construir. En un enfoque lean, se crean y recopilan continuamente métricas sobre lo que estamos creando. Los experimentos y las hipótesis se validan de forma continua, creando prototipos y validándolos con los usuarios, en un ciclo continuo de creación y test.

Agile es una metodología creada por desarrolladores que ven la creación del producto desde su perspectiva, con el objetivo de crear software funcional de alta calidad de la forma más rápida y eficiente. Pero esto implica la colaboración de personas, y por lo tanto la metodología agile ofrece un cambio de paradigma sobre la forma de trabajar de los equipos y en especial afecta a los profesionales de UX y sus entregables, los cuales han de entregar documentos orientados a la colaboración con los desarrolladores.

UX tradicional, agile y lean (Anders Ramsay)

Lo cierto es que ambas metodologías se pueden solapar según las necesidades del proyecto, y cada organización suele tener el coctel metodológico que le ofrece mejores resultados.

Organizaciones diferentes, profesionales diferentes

Posiblemente los dos principales factores que determinan la diferencia entre un trabajo de diseño brillante y uno mediocre, son el contexto y la cultura de la organización: el tiempo, la falta de recursos, cambios en la estrategia, conflictos de prioridades entre los miembros… Como comentaba hace tiempo Alan Cooper, los problemas en el producto son los síntomas de que algo va mal en la organización.

Por lo general, la figura del diseñador o experto de UX en una organización se acerca más a la del gestor o el manager. Hay organizaciones en las cuales tiene un papel protagonista y directriz, y otras en las que su figura es más de mediador entre negocio y tecnología. Dependiendo del contexto de trabajo, la figura y el rol del diseñador de UX variará para adaptarse a las peculiaridades de la organización.

Kim Goodwin, en su charla “Your Toughest Design Challenge” del User Interface 17 en Boston, apuntaba cuatro tipologías de organizaciones: las adhocracias, los clanes, las jerarquías y los mercados. Según Goodwin, cada una de ellas requeriría un perfil de profesional de UX con ciertas peculiaridades:

Adhocracia

Son organizaciones en las cuales reina un caos generalizado, no existe ningún proceso consolidado y las cosas están siempre en constante reinvención. Hay una cierta resistencia la documentación pero sin embargo son organizaciones donde prima la novedad, la experimentación y están centradas en el crecimiento.

Los profesionales de la UX en una adhocracia son “ninjas de pizarra”, que traducen la visión del grupo en diseños funcionales, elaborando prototipos rápidos y recogiendo el feedback de los usuarios y del resto del equipo para avanzar en los proyectos.

El Clan

Organizaciones donde se presta mucha atención a las relaciones laborales. En los clanes las cosas toman mucho tiempo, todo el mundo participa de las decisiones. Las reuniones suelen ser largas y con muchos participantes, no hay una atribución clara de las responsabilidades y se evitan los conflictos.

En los clanes los profesionales de la UX son facilitadores y entrenadores. Su labor es muy pedagógica e invitan al resto del equipo a su proceso de investigación y diseño, donde se potencia el intercambio de ideas y el aprendizaje del colectivo.

La jerarquía

Organizaciones con mucha especialización. En las jerarquías existen procesos rígidos, roles y títulos de trabajo, sus miembros están enfocados hacia el interior de la organización y hay una cierta aversión al riesgo.

De hecho, el la reducción del factor riesgo es el argumento que más vende en las jerarquías, por esta razón, los profesionales de la UX en una jerarquía son expertos. Son fuentes de confianza que aseguran el mínimo error posible en la implementación de los proyectos.

El mercado

Los mercados son compañías enfocadas al exterior, donde los productos se elaboran a partir de la investigación, la monitorización y la agilidad. El rol del profesional de UX dentro de un mercado se parece al de un científico, el cual puede medir la implementación de todas las decisiones de diseño (por pequeñas que sean) y demostrar su impacto mediante el análisis de datos.

Independientemente del rol dentro de la organización, el papel del Diseñador de Experiencia de Usuario, será el de facilitador, educador, constructor empatía y defensor del usuario / cliente. No sólo es experto en el usuario, sino que es el experto en el proceso. Ha de saber qué herramientas y técnicas a utilizar en según la situación y el estado del proyecto, haciendo las preguntas correctas y dando sentido a las respuestas.

Los profesionales más destacados no sólo evangelizan los principios y la filosofía de la experiencia del usuario en su día a día, sino que además involucran a todo el equipo y construyen una cultura de trabajo en toda la organización.

No obstante, a pesar de la enorme evolución y especialización entre los profesionales, sigue existiendo una sensación de incertidumbre y dinamismo, inherente al trabajo de diseño y a la inexistencia de soluciones absolutas.

It depends (Kevin Cheng)

UXSpain y la necesidad de un encuentro entre profesionales

Pese a estas diferencias y peculiaridades, los profesionales de la UX siempre se han caracterizado por compartir los recursos e intereses con la comunidad de una forma u otra, por lo general de forma virtual, y en los últimos años se había producido un gran lapso de tiempo sin ningún evento que sirviera como pretexto para desvirtualizar y aglutinar en un mismo espacio físico a la comunidad de UX en España.

UXSpain se presentó en su primera edición el año pasado, como una nueva oportunidad para sumar esfuerzos, así como un espacio de reflexión y encuentro para construir comunidad. El evento superó todas nuestras expectativas, superando en más de 400 personas el número de asistentes, y sirvió como detonante de otros eventos y actividades en diferentes ciudades que han propiciado el lanzamiento de propuestas innovadoras con las que seguir aprendiendo.

Para la edición de este año, el encuentro sigue manteniendo su misma filosofía, se organiza sin ánimo de lucro y todos ingresos de destinan a sufragar los gastos del evento. Tendrá lugar los días 10 y 11 de mayo en Valladolid y tendremos a nuestra disposición un edificio completo: el Palacio de Congresos Conde Ansúrez, de la Fundación General de la Universidad de Valladolid. Esperamos poder disfrutar tanto como lo hicimos el año pasado.

Bibliografía

Osteópatas

23 Ene, 2012, por Sergio.

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.

Affordances, luces y sombras de la modernidad

6 Nov, 2011, por Sergio.

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.

Nuevo diseño de Gmail

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:

Diseño del botón actual de Google

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:

Bisel interior para elevar el botón de la superficie.

Ahora parece un poco más pulsable, pero podemos hacerlo más evidente añadiendo algunos matices:

Degradado lineal, para realzar la iluminación superior y el aspecto tridimendional.

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:

Sombra inferior para potenciar más el aspecto tridimensional.

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.

Escaleras, pendientes y tropiezos

10 Oct, 2011, por Sergio.

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).

Pendiente de escalera

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.

Diseño formularios

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.

Check-in

24 Jul, 2011, por Sergio. 2 Comentarios

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.

Hardcore will never die, but you will

18 Mar, 2011, por Sergio.

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.

Verificando las ruedas

16 Ene, 2011, por Sergio.

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.

Trabajador del transiberiano verificando 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?

Magia Potagia

16 Nov, 2010, por Sergio.

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…

Egoless Design

4 Nov, 2010, por Sergio. 1 Comentario

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:

  1. 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.
  2. 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.
  3. Alike critique design instead of people. As much as possible, make all of your comments positive and oriented to improving the design.
  4. 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.
  5. 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…).
  6. 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.
  7. 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.