Estrategias de diseño: Prototipado (y propósito)

Los prototipos son artefactos que nos ayudarán a simular el comportamiento y el aspecto que tendrá la solución que queremos plantear. Independientemente de la fidelidad que tengan, los prototipos pueden ayudarnos a comunicar o a explorar ideas de diseño que favorezcan determinadas experiencias a nuestros usuarios.

Propósito y niveles de fidelidad

Vamos a ver cómo en sus diferentes niveles de fidelidad nos pueden ayudar a explorar una idea, comunicar una visión, descubrir alternativas y validar una solución antes de que cueste demasiado tiempo o dinero.

Durante el proceso de prototipado lo que estamos intentando hacer es reducir la incertidumbre de si la solución va a ser finalmente un éxito desde el punto de vista del usuario.

Por otra parte, incluso durante el proceso de investigación de usuarios, podemos usar los prototipos para ilustrar y modelar todos esos escenarios de uso que simulan situaciones de uso real y su contexto tecnológico. No hace falta ser un artista para esbozar estos escenario que sin embargo nos van a aportar mucho valor a la hora de visualizar el problema.

Propósitos:

  • Describir un problema
  • Explorar ideas
  • Comunicar una visión
  • Especificar una solución
  • Testear con usuarios

Durante el proceso de diseño nos vamos a encontrar que en sus diferentes fases necesitemos expresar ciertas ideas, algunas buscan un propósito concreto, como decía no es lo mismo diseñar para comunicar que diseñar para explorar, o para validar. Los tipos de prototipos que podemos hacer no son necesariamente excluyentes, es decir, no cumplen una única función ni son creados en un único momento. Si bien es cierto, debemos ser capaces de entender qué nos ofrece cada uno en cada momento para saber interpretar un un prototipo (ya sea porque lo ha creado un diseñador, un product owner, un cliente o el equipo de desarrollo en su conjunto).

Muchas veces si no estamos muy acostumbrados a hacer un prototipo nos cuesta saber cómo representar ciertas cosas y o pensamos que no somos muy buenos dibujando y por esto no debemos diseñar. Como casi todo en la vida, diseñar es también cuestión de práctica. Un ejercicio interesante para practicar si no os atrevéis a lanzaros al canvas en blanco es partir de una app que os guste o que uséis a menudo y tratar de identificar el layout, los componentes básicos, la navegación principal y secundaria y otros elementos gráficos de forma que cumplan un propósito para la composición final. Desde fuera hacia adentro, desde la estructura hasta los detalles.

A partir de ahí acostumbramos a nuestros ojos a ver estructuras y patrones. Una vez tengamos esta primera composición podemos seguir distinguiendo visualmente los elementos interactivos y el sistema de navegación que se deriva de la interacción.

Niveles de fidelidad

Elegir el nivel de fidelidad de cada prototipo es algo crítico ya que debemos balancear el impacto que tenga en el proceso versus el tiempo dedicado a crearlo. Cuando hablamos de fidelidad nos referimos a cómo de cercano al producto final parece el prototipo. El nivel de fidelidad centrará el feedback recibido sobre un aspecto u otro del diseño, es por esto que tenemos que tener en cuenta el objetivo.

Cuando prototipamos podemos entender la fidelidad tanto por el grado:

  • Baja
  • Media
  • Alta

Como por la dimensión:

Generalmente cuando empezamos a prototipar empezamos siempre por algo de baja fidelidad y vamos pasando a añadir mayor número de detalles conforme los conceptos básicos están claros. Sin embargo no hay reglas escritas, hay que ser flexibles para decidir qué es lo apropiado en cada momento y cuando creemos que un diseño está suficientemente “terminado”.

Low 

High

  • Rápido
  • En el momento preciso y en cualquier momento
  • Barato
  • Desechable
  • Crea un vocabulario claro
  • Imprecisos y por tanto flexibles y abiertos
  • Poco detalle y poco refinado
  • Sirve para sugerir y explorar
  • Ambiguo
  • Propositivo
  • Cuestiona el problema
  • Descriptivo
  • Nivel de detalle medio-alto
  • Testable
  • Especifica la solución
  • Es didáctico
  • Demostrativo
  • Comunicativo
  • Criticable
  • Interactivo
  • Cercano al producto final

  

Storytelling

Prototipar interfaces no es la única forma de comunicar las ideas de diseño, de hecho, en determinadas fases de un proyecto resulta mucho más interesante combinar estos prototipos con una historia que ayude a entender el contexto y el trasfondo del problema que se intenta explicar.

La técnica de Storytelling también es una herramienta más de los/las diseñadores/as de experiencia de usuario. Para contar una historia relacionada con los usuarios y su experiencia podremos hacerla a través de fotos, vídeos, audios o simplemente escribirla y contarla. El objetivo será describir una situación, ilustrar un problema, explorar un concepto de diseño, etc.

Sin embargo, aunque mucha cree que contar historias es una forma de difundir una idea, el objetivo principal es que ésta resulte interactiva y conversacional. Una buena historia creará en tu audiencia preguntas y comentarios que ayudarán a construir una mejor narrativa.

Con buenas historias la descripción de los problemas debe afrontarse desde un presente real (personas) hasta un futuro deseable (escenarios).

¿Es el prototipado parte integral de la estrategia de diseño?

El proceso de diseño lleva consigo la iteración y acercamiento desde una idea abstracta hasta la especificidad de una solución concreta. Las diferentes versiones de ese diseño y el proceso por el que pasa todo el razonamiento desde la hipótesis inicial hasta la tesis final pueden formarse en base a prototipos que resulten testeables o al menos sirvan como herramienta para la comunicación.

En mi opinión prototipar teniendo en cuenta tanto el propósito como el nivel de fidelidad es clave para alcanzar una solución que realmente resuelva los problemas de los usuarios, sin embargo, esto no significa que saltar de una idea abstracta a un producto final con ‘pocos’ prototipos hace que estemos aplicando una peor metodología de Diseño Centrado en el Usuario. A fin de cuentas, la experiencia, la velocidad y la capacidad de iteración son cosas que dependen del equipo, el hecho de decidir si un prototipo es algo construido con una herramienta de diseño o con código es una cuestión que se decide según las capacidades y recursos de cada equipo.

En mi experiencia he adaptado mucho tanto la técnica como el propósito según las necesidades del proyecto, al igual que mi propia forma de construir propuestas, la cual hace que cada vez necesite menos pasar por ciertas etapas y sin embargo me obliga a crear más y más versiones en otras.

 

Prueba de diseño en Cinefilica

Así de chulo me está quedando el nuevo diseño de Cinefílica, pero tengo mis dudas sobre si publicarlo. El layout responsivo funciona pero me está dando muchos quebraderos de cabeza para encajar ciertas cosas.

Quitarme de un plumazo la navegación es un decisión muy radical. Si bien podría confiar en la página de inicio como distribuidor de contenido y potenciar el buscador (y sus resultados) para darle al usuario todo lo que necesita explorar, me quito la posibilidad de extender en algún momento el sitio web a algo más que el catálogo.

Otra cosa que hago desaparecer es el pie, creo que debería incluirlo aunque muchísimo más discreto que lo que hay ahora. Eso sí, los géneros debería hacerlos más visibles en la página de inicio, a fin de cuentas, están recibiendo visitas.

No sé si acabaré publicando estos cambios, en cualquier caso aquí los comparto.

Usando Axure para definir interacciones con contenido dinámico

No soy la persona más fan del mundo de Axure, me parece complicado y anticuado. Axure es una herramienta de prototipado, una de las más populares y una de las potentes. Pero sigue estando muy orientada a interfaces web sin embargo

  • No resuelve bien el diseño de web responsivo
  • Las animaciones son programáticas (no hay timeline de animaciones)
  • Las animaciones y los estados de los paneles dinámicos no se llevan bien
  • Hay demasiadas malas prácticas que pueden llevarte a hacer insostenible el mantenimiento de un proyecto

En cualquier caso reconozco que es una de las más completas y se pueden cubrir la mayor parte de los prototipos que se quieren hacer sin necesidad de saber programar y sin necesidad de abrir otras herramientas de diseño.

Además dotar de vida a un prototipo estático es una gran oportunidad para empezar a sentir cómo va a ser el uso real del producto. La pregunta es sobre quién queremos que caiga el esfuerzo de la creación de dicho prototipo ¿sobre el diseñador o el desarrollador? Es más ¿es un prototipo que se use sólo para decidir o también para testear?

El debate sobre qué nivel de fidelidad y de interacción debe tener un prototipo la dejo para otro momento, ahora me quiero centrar en descubrir alguna de las cosas interesantes que se pueden hacer con Axure que, si bien no resultan obvias a primera vista, no son tan complejas después de todo (eso sí, de aquí a programar hay un paso pequeñito).

Gestión de contenido dinámico

Algo que da muchísimo valor a un prototipo es el uso de datos y contenido real. En muchos casos, si el diseño de la información es bueno, cualquier otro elemento de la interfaz pasa desapercibido.

La forma de usar datos dinámicos con Axure es mediante el componente repeater.

Un repeater no es más que un contenedor de elementos que se pueden repetir con valores diferentes y con misma apariencia. Es decir, es como una tabla pero sin tener datos fijos.

A un repeater se le pueden añadir filas, eliminar y modificar como quieras. Además se le pueden añadir y eliminar filtros y un criterio de ordenación e incluso paginarlos.

Lo interesante de los repeater es que se pueden usar para definir el modelo de datos de la aplicación donde se pueden gestionar elementos de navegación dinámicos (como un sistema de pestañas), listas de elementos gestionados por el usuario (por ejemplo una lista de películas favoritas) o simplemente un historial de acciones (que pueden usarse para deshacer a un estado previo).

Variables globales

Otra gran utilidad de Axure son las variables globales. De nuevo un elemento muy práctico para quienes necesitan orquestar la lógica del prototipo de forma que todo esté coordinado.

Las variables globales se pueden instanciar en cualquier momento disparado por cualquier evento de cualquier componente y ayudan a mantener el estado de la interfaz.

Pero ¿por qué necesitaríamos estados? Seguramente en el mundo web donde casi 90% de lo que se hace es navegación lineal vuestros prototipos a base de hiperenlaces sean suficientes. Sin embargo, cuando quieres prototipar una interfaz de usuario donde el usuario puede interactuar con muchos componentes a través de ratón o teclado, existan ciertos elementos cuyo comportamiento va a depender de la combinación de dichas interacciones, es decir, del estado en el que esté la interfaz en cada momento. Para conocer dicho estado, usar variables globales resulta tremendamente práctico.

Pencil

Herramienta de prototipado de código abierto multiplataforma

Si la austeridad también ha llegado a su ciudad, como el camión del tapicero, quizá guste de conocer esta interesante herramienta de prototipado de baja fidelidad totalmente gratuita y disponible para Linux, Windows y Mac.

Pencil no es nada nuevo ni bohemio ni cool, de hecho la última release es de Septiembre de 2013 y no da la impresión de que el proyecto siga vivo, pero no podemos negar que como herramienta es bastante útil si quieres empezar a trastear con el diseño de pantallas desde ya, además es gratis, es libre y el resto depende de tu imaginación (como siempre). 

Pencil Project nació en 2008 y se distribuye bajo términos de licencia GPL version 2, y es una herramienta muy sencilla que permite hacer cosas tan básicas como:

  • Dibujar diagramas
  • Sketchear GUIs basadas en componentes predefinidos
  • Relacionar documentos de un proyecto mediante enlaces de contenido
  • Exportar los documentos como imágenes o un documento HTML (aunque éste sea bastante precario)
  • Definir tus propia librería de componentes (muy útil para equipos de diseño)

Sobre éste último punto he publicado un pequeño artículor en el que explico cómo hacerlo.  Aquí os dejo el enlace por si os pica la curiosidad: Cómo crear una librería de recursos con Pencil.

Cómo crear una librería de recursos con Pencil

Si ya conocéis Pencil y os preguntáis cómo podríais definir vuestra propia librería de componentes para crear GUI en este tutorial hacemos un repaso de los pasos a seguir.

Hay dos formas de conseguir nuestra propia librería

  1. Haciéndolo bien
  2. Haciéndolo rápido

Como para hacerlo bien ya existe una buena documentación en la web de la herramienta vamos a explicar cómo puede hacerse de forma rápida (y no tan flexible) para que resulte práctico crear conceptos visuales y compartirlos con diferentes equipos.

image

Una forma fácil de empezar

Usando la librería ‘Common shapes’ podemos empezar a dibujar elementos básicos basados en formas geométricas.

  1. Una vez que tengamos todos los elementos, los seleccionamos juntos y agrupamos (CTRL+G). Ahora se comportarán como una única forma.
  2. Sobre el nuevo componente clicamos en botón derecho “Add to my collections…”.
  3. Como este es el primer componente tendremos que crear una nueva colección a la cual añadirlo. 
  4. Si ahora comprobáis en la pestaña ‘My Stuff’ veréis que ya está creada vuestra nueva colección. 

Una característica que encuentro bastante útil es la ‘Sizing policy’ que tiene cada elemento (accesible via menú contextual). Esta política permite definir el comportamiento del elemento cuando está agrupado en un componente al que se le modifica el tamaño. Gracias a esto podrás decidir si quieres que cambie o no de tamaño o se mantenga alineado a un lado o a otro.

¿Y si quiero hacerlo bien?

Qué necesitas tener

  • Un editor de texto (para ver/editar XML)
  • Un editor de SVG (las formas están definidas como vectores)
  • Un editor de bitmpas (por si necesitas meter algún icono o imagen)

Qué necesitas saber

Una estructura típica para crear una colección tiene este aspecto

... [dir] CollectionName
      |
      |___[dir] icons       #optional
      |     |
      |     |___shape1.png
      |
      |___ Definition.xml     

y en el documento Definition.xml deberás definirlo de esta forma

<Shapes xmlns="http://www.evolus.vn/Namespace/Pencil"
        xmlns:p="http://www.evolus.vn/Namespace/Pencil"
        xmlns:svg="http://www.w3.org/2000/svg"
        xmlns:xlink="http://www.w3.org/1999/xlink"

        id="your_collection_id"
        displayName="Display name of your collection"
        description="More description about this collection"
        author="Names of the authors"
        url="Optional URL to its web page">
        
        <!-- Your shapes go here -->
        
</Shapes>

Iremos añadiendo los diferentes componentes usando las etiquetas <Shape></Shape> y dentro de ellos podremos definir Propiedades (color, dimensión, etc.), Comportamientos y Acciones además de su Aspecto (mediante el SVG).

Para ver lo que estamos haciendo, puedes cargar tu colección desde Tools » Developer Tools » Load Developer Stencil Directory… seleccionando el archivo Definition.xml (usa F5 una vez cargado para refrescar).

Cuando termines, mételo todo en un archivo ZIP asegurándote que el Definition.xml está en la carpeta raíz.

No te olvides que si quieres depurar errores puedes abrir la consola de errores desde Tools » Developer Tools » Show Error Console

A partir de aquí te recomiendo que consultes el Tutorial en el que viene explicado cada detalle sobre cómo montar la colección con directivas XML.

Interaction Design with Indigo Studio and GifCam

Interaction Design with Indigo Studio and GifCam.

Indigo first release was free forever, although it’s not available for download any longer. I’m one of the few who still have a Lite license and can take advantage of this powerful prototyping tool built in Silverlight.

Indigo has helped me to demonstrate design, simulate behaviour and communicate specifications with the development team and also with end users.

GifCam is just a cool resource that helps me to share microinteractions implemented with a prototyping tool.

And this ‘Hello World’ example is nothing but one of the design interactions in motion I’ve been working this morning 🙂

Selectores de género

littlebigdetails:

Instructables – Offers a variety of gender options when signing up for an account

/via Vonn

Interesante detalle. En el ámbito clínico este tipo de datos es punto de controversia. Por un lado hay usuarios para los que este dato al no ser clínicamente relevante desprecian su utilidad, por otra parte ciertos estándares obligan a especificarlo de acuerdo a un respeto a la identidad de género del paciente, para otros, el dato es clínicamente relevante cuando se ajusta a la realidad fisiológica del paciente.

La solución: diferenciar entre Sexo (Biológico) y Género (Identidad), puesto que tenemos que seguir educando a la ciencia y a la conciencia de que las diferencias existen porque son relevantes y que deben ser las personas (los usuarios en este caso) los que interpreten los datos y decidan qué significan para ellos.

Relacionado con la interpretación o cómputo de datos clínicos y la forma en que se muestran encontramos también la ocurrencia de riesgos clínicos.

One design to rule them all?

image

Today I wanted to get some clarity about a way to efficiently approach the UX design when targetting multiple mobile devices. You know, to deserve my holidays.

During my research, I’ve needed to take apart aspects like the Interaction design and get focused only on the very basic initial challenge: the app structure and navigation. I’ve also centred the research within the smartphone scope by considering only Android, iOS7 and Windows Phone 8.

These are some early ideas I’d like to investigate further:

  • The commonalities and diferences between the in-built functionalities like Search, Notifications, Multitasking, Back vs Up navigation and in-app navigation.
  • A compliance layout, app structure and navigation which naturally fits into the different platforms according to their guidelines.
  • A translation (if exists) between the different navigation patterns (flat, hierarchical, etc.) and the recommended UI controls (Tabs, Toolbars, Segmented control, etc.)

So I’ll continue digging into the guidelines and trying some design to validate (or not) the hypothesis “One” design to rule them all might be difficult but not impossible, it is, actually, needed.

Cheers